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ON THE FRONT LINE OF GAME INNOVATION 



PLAN 




Down With Global 
Homogenization! 



I think most of us in this industry 
are pretty happy about the fact 
that interactive electronic enter- 
tainment has rapidly become a 
widespread form of entertainment 
around the world. And in case you 
didn't notice, game development itself 
has spread around the globe with simi- 
lar speed. This fact was made abundant- 
ly clear to me last year when entries for 
the G DCs I ndependent Games Festival 
poured in from far-flung countries like 
Poland and Pakistan. (That was a bit of 
a mind-blower.) It really makes you 
realize that there's much more to this 
industry than meets the eye at E3, 
ECTS, and theTokyo Game Show. 

What's becoming increasingly clear to 
me is that many overseas game develop- 
ers want to come to America. I know 
this firsthand, because! regularly get 
asked to write letters of reference for for- 
eign game developers trying to make 
their way through theU.S. Immigration 
and Naturalization Service bureaucracy. 
While my experience isjust anecdotal, 
I've spoken to enough game executives 
around the industry to know that many 
American companies actively recruit 
overseas game development talent. 

It's probably not too tough to entice a 
foreign developer over here. It's no 
secret that American companies pay 
game developers more than those in 
most other countries (and that probably 
holds true for most professions). A 
salary survey conducted last spring by 
the Miller Freeman Game Group (which 
this magazine is affiliated with) and 
M arket Perspectives revealed that the 
average total salary — including any 
sort of cash bonus — for an American 
game programmer in the U.S. was 
$49,991, and the median total salary for 
a game programmer was $50,000. 
Compare that to a Polish company that 
we recently talked to, which pays its 
staff programmer the equivalent of 
about five hundred U.S. dollars per 
month. Though thecost of living in the 
U.S. is substantially higher, that magni- 
tude of a discrepancy I ures many for- 
eign game developers away from their 
native lands. 
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As an American, however, I must 
admit to having reservations about an 
influx of foreign talent. It's not that I 
think American jobs will be stolen by 
immigrants, nor that I adhere to isola- 
tionist beliefs. On the contrary, I say 
the more the merrier herein the U.S. 
What I fear is the result of a slow, 
steady exodus of game developers from 
countries whose game industries are 
just beginning to form. I don't think 
that's good for the countries in ques- 
tion, nor for their burgeoning commu- 
nities of game developers. Sometimes 
all it takes is a few key people leaving a 
team to kill a game, and in some coun- 
tries, the development of a single com- 
mercial game is a real feat. 

I also feel (and I think many would 
agree) that our industry needs to 
explore more game designs, and I fear 
anything that will homogenize game 
development. Cultural differences 
between countries make many titles 
extremely entertaining, simply due to 
their (for lack of a better term) exotic 
design. When I first saw Parappa and 
Dance Dance Revolution, I knew 
they weren't developed in America. 
There is something distinctly Japanese 
about them which I really enjoy. It 
would be a pity to lose some of that 
diversity in favor of Yet Another FPS. 

In thenewspaperthismorning I read 
that French chefs staged a protest in 
Paris, in part to voice their anger against 
America's growing economic and mar- 
keting muscle overseas— in this case, 
McDonald's was the object of their 
scorn. The French want no more of our 
fast food, music, and movies. They 
probably still hold Euro Disney against 
us. And while I used to write these com- 
plaints off as poor sportsmanship in the 
arena of international business, I'm 
coming around to see that it's impor- 
tant to grow our industry outside the 
clutches of Uncle Sam. 

Sigh. Maybe a croissant will cheer 
me up. ■ 
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New Products 



bif Jennifer Ol^en 



But Does It Walk the Walk? 

LIPS INC. has developed Ventriloquist, a 
plug-in designed to aid animators by 
automating the complex task of lip- 
synching facial animations to audio 
files. Typically, facial animation is a 
grueling process for animators. To do it 
correctly, one practically needs an 
advanced degree in linguistics to figure 
out all the phonemes, vi semes, and 
every other -eme one needs to master 
before a speaking character is ready for 
its close-up. What Ventriloquist aspires 
to do is to let animators plug character 
dialog straight in from one of numer- 
ous standard audio file formats, and 
then quickly and painlessly deliver an 
output stream of precise morph targets. 

The immediate results from this 
process look admittedly stilted, but a 
one-size-fits-all answer to the infinite 
range of human (or animal, or robot, 
or alien) emotion and expression is a 
tall order. By the time animators are 
ready to keyframe the finishing touch- 




Ventriloquist brings easy lip-syncliing to Max. 



es they've already saved a lot of time, 
which they can then spend tweaking 
those faces to perfection instead of 
sweating the set-up. 

Ventriloquist is appearing first for 
3D Studio Max 3 at a suggested price 
of $595. Versions for Lightwave, Soft- 
image, Maya, and others are to follow 
soon. 
■ Lips Inc. 

Gary, N.C. 

(919) 468-7005 

http://www.lipsinc.com 

Common Environment Still Uncommon 
for Consoles 

MICROSOFT has released the Windows 
CE Toolkit 2 for the Sega Dreamcast. 
With the advent of the Dreamcast, con- 
sole development is finally emerging 
from its smoke-filled room, no longer 
the arcane process associated with the 
current, aging generation of consoles. 
Sega is banking that it will be able to 
attract more developers already familiar 
with the Windows CE development 
environment to their new console. 

Windows CE for Dreamcast means 
that porting games between Dreamcast 
and PC will be relatively easy, and is 
^^^^^^^^ sure to encourage more 
simultaneous cross- 
^ platform development 

. since many of the 

flHft hardware barriers of 

^^^^H ~ j traditional console 
^^^^H development will be 

„^^^| I ^ mitigated or eliminated 
"5r*_ altogether. Memory- 
light but feature-rich, 
the Tool kit of course 
incorporates the 
DirectX library of APIs 
and is compatible with 
Visual C-H-and Visual 
Studio. 

One new feature of 
the Tool kit that may 
prove interesting for 




New Products: Lips inc. yaks it up 
with Ventriloquist, M icrosoft whips out 
new CE for Dreamcast, and Sonic 
Foundry takes another trip. p. 9 



Industry Watch: Sony seeks desktop 
real estate, Titus nibbles at Virgin 
Interactive, and Sierra lets fly an 
avalanche of canned titles, p. 10 



Product Review: Jeffrey Abouaf puts 
Mirai, Nichi men's new 3D modeling 
and animation package, through the 
wringer, p. 12 

Dreamcast development is its browser 
support. Internet Explorer 4 HTML 
Control enables developers to give 
players access to HTM L content from 
within a game so they can post high 
scores, link to hints and cheats, and 
lose some of that excess disposable 
income with e-commerce functionality. 

■ Microsoft Corp. 
Redmond, Wash. 
(425) 882-8080 

http://msdn.microsoft.com/cetools/ 
platform/support.asp 

Another Loopy Trip for Musicians 

SONIC FOUNDRY introduced a new ver- 
sion of Acid Pro, its groundbreaking 
loop-based music production tool. 
When it debuted in 1998, Acid thrilled 
music professionals with its ability to 
change tempos without altering pitch. 

New to Acid 2 is Sonic Foundry's 
XFX 1 DirectX audio plug-in which 
enables real-time tweaking of mixes. It 
also includes Sound Forge XP 4.5, a 
digital audio editor that lets users cre- 
ate and edit loops, synchronize audio 
and video, and manage file conversion. 
Hundreds of royalty-free loops are 
available that users can simply drag 
and drop from the explorer window 
into their track view and arrange into 
multiple-track creations. Acid automat- 
ically adjusts the key and tempo of 
incoming loops to keep things from 
getting out of whack, which means less 
dirty work for you, the artiste. 

Once your magnum opus is com- 
plete, you can output your music to 
.WAV, .MP3, .WMA, or .RM files, 
export as digital audio tracks, or burn 
it on CD with track-at-once CD burn- 
ing. Acid Pro 2 is aval I able for 
Windows 95/98/NT 4.0 and carries a 
suggested price of $399. 

■ Sonic Foundry Inc. 
Madison, Wis. 
(608) 256-3133 
http://www.sonicfoundry.com 
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Industry Watch 

btf Daniel Hwehner 



PLAYSTATION GOES DESKTOP. Accord 
ing to some reports, Sony plans to fol- 
low the M arch release of the Play- 
station 2 with a series of desktop 
workstations based on the console's 
Emotion Engine processor. SCEA chair- 
man and CEO Ken Kutaragi noted that 
the current Emotion Engine is equal to 
Intel's Pentium lllin transistor count, 
and he expects the next-generation 
Emotion Engine 2 to surpass the 
Pentium when it's released in 2002. 
The workstation will be aimed primari- 
ly at users in broadcasting, film pro- 
duction, and software development. As 
we went to press, Sony had yet to com- 
ment on an OS, but it is suspected that 
Linux will power the new systems. 

CODEMASTERS PICKS UP YOSEMITE. A 

closed studio will gain new life in the 
so-called "birthplace of computer gam- 
ing." U.K.-based Codemasters has 
announced a plan to open a studio in 
Oakhurst, Calif., a town that gained 
notoriety as the home of Sierra's first 
headquarters 20 years ago. M uch of the 
staff and management of the new stu- 
dio will be veterans of Sierra's Yosemite 
Entertainment studio. Craig Alexander, 
who served as Yosemite's general man- 
ager for nearly five years and directed 
games such as Phantasmagoria and 
Police Quest: SWAT, will lead the 
group. The studio is expected to start 
with two dozen employees and ramp 
up to 70 in the coming months. The 
group will keep the Yosemite name, 
which was purchased from Havas, and 
will pursue development of both PC 
and PS2 projects. 







Amen: The Awakening has gone into 
hibernation, at least for now. 



TITUS TAKES VIRGIN INTERACTIVE. 

Acq u i si ti ve Fren ch pu bl i sh er Ti tus con - 
tinued its expansion by purchasing a 
controlling interest in Virgin Interact- 
ive, a move that should further bolster 
Titus's position in Europe. The firm 
gained a 43.9 percent share in Virgin as 
part of an earlier deal to take control- 
ling interest in Interplay. Titus pur- 
chased additional shares to expand 
that stake to 50.1 percent and a con- 
trolling interest in the company. The 
terms of the sale were not disclosed, 
and neither company has yet com- 
mented on its plans. 

SIERRA PULLS PLUG ON BABYLON 5. In 

what was billed as a move to "enhance 
focus on market success," Sierra killed 
off several titles and eliminated 105 
jobs. The cancellation of Desert Fight- 
ers and Pro Pilot Paradise at Dynamix 
in Eugene, Ore., sent 60 employees 
packing. An additional 45 jobs were 
lost with the cancellation of Babylon 
5, a title that had been relocated to 
Bel I evue. Wash . , after Si erra sh uttered 
Yosemite Entertainment earlier this 
year. Other titles cut in the restructur- 
ing included Orgs: Revenge of the 
Ancients and the persistent- world pro- 
ject Middle-Earth. The reorganization 
will ultimately see Sierra divided into 
three business units: Core Games will 
focus on Sierra's high-profile games 
and includes Half-Life publisher Sierra 
Studios, Impressions Games, Papyrus, 
Sierra Northwest Studios, and the 
remaining teams at Dynamix; Casual 
Games will focus on Hoylecard games 
as well as hunting, fishing, and rodeo 
titles; and Home/Productivity will deal 
with cooking, gardening, and genealo- 
gy titles. 

AMEN DESIGN STAFF DUMPED. Cave^ 
dog Entertainment, well-known maker 
of strategy games Total Annihilation 
and TA: Kingdoms, cited problems 
with the technological development 
of its much-anticipated shooter Amen: 
The Awakening as the basis for its deci- 
sion to let go of the entire Amen 
design staff and push back the game's 
release date. While Cavedog hasn't 
elaborated on the game's problems, 
the design staff were praised for their 
"talent, dedication, and contribution" 
and were invited to return to the pro- 
ject when, and if, the development 
difficulties are resolved. 



BALLARD RESIGNS FROM 3DFX. 

L. Gregory Ballard tendered his resigna- 
tion as chief executive officer of 3dfx 
effective October 31, 1999. Ballard 
spent three years at the company, see- 
ing revenues grow to more than $400 
million. "I truly believe that the chal- 
lenges in this next phase of the compa- 
ny's growth will be more technical 
than marketing and strategic, and that 
Bdfx can benefit from the fresh per- 
spective that a new CEO can bring," 
said Ballard. 3dfx is forming a search 
committee, which Ballard himself will 
lead, to find a replacement. ■ 



UPCOMING EVENTS 

CALENDAR 



Digital Content Creation 

LOS ANGELES CONVENTION CENTER 

Los Angeles, Calif. 
December 6-8, 1999 
Cost: variable 
http://www.dccexpo.com 



Gome Developers Conference 
HordCore Technical Seminars 

HYATT REGENCY 

SAN FRANCISCO AIRPORT 

Burl in game, Calif. 

Physics: December 6-7, 1999 

Graphics: December 8-9, 1999 

Cost: $l,950/each; $3,300/both 

http://hardcore.gdconf.com 



Gome Developers Conference 
1999 RoodTrips 

WYNDHAM GARDEN HOTEL 

San Rafael, Calif. 
December 10, 1999 

MEYDENBAUER CENTER 
Bel I evue. Wash. 
December 14, 1999 

Cost: $120 ea. (discounts available) 
http://roadtri ps.gdconf.com 
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Nichimens 
'^Mirai 

btf Jeffrey flhawaf 

If you attended Siggraph '98 in 
Orlando and rested your feet at 
the Nichimen booth, you saw the 
promise of something new in character 
animation: M irai. The promise was 
realized with the product's release last 
May, followed by unanimously positive 
critical reception. It brings many firsts 
to character animation, and is well 
worth looking at whether your pas- 
sions run to cinematic or real-time 3D. 

The most noticeable innovation is 
the degree of skeletal intelligence built 
into the animation module. The first 
demo involved a generic bipedal char- 
acter performing a gymnastic exercise 
— taking two running steps toward a 
wall, kicking one foot against the wall 
to push up and off into a backward 
somersault, catching a trapeze, then 
dropping to the floor. The naturalistic 
motion sequence took about two min- 
utes, required only eight keyframes, 
and was actually usable. The second 
part of the demonstration involved 
the artist refining and smoothing the 
model, texture-mapping it, and 
adding touch-up paint, all from with- 
in Mirai, with changes updated across 
all modules in real time. No doubt 
that first demo belied the technologi- 
cal advances under the hood, because 
Mirai didn't ship until thefollowing 
May. M irai's power and advantages are 



more subtle and far-reaching than the 
demo showed: it begins with a work- 
ing environment, which strives to be 
more like a 3D operating system than 
a user interface, and builds on this 
with a comprehensive, advanced fea- 
ture set. 

A 3D OPERATING ENVIRONMENT. Some 
leading 3D applications have a Ul 
organized into modules (modeling, 
animating, rendering, and so on); oth- 
ers perform all operations within a 
single perspective window, enhancing 
this with a series of modeless dialog 
boxes. Each approach has its strengths 
and limits. Of the former, few, if any, 
let you work in more than one mod- 
ule at a time; of the latter, the single 
interface is usually supplemented by 
floating dialogs. M irai's designers con- 
ceived the interface as a 3D operating 
system, in which modules behave like 
applications, each complemented 
with its own floating dialogs, yet all 
are dynamically linked so changes to 
one propagate through the others 
instantaneously. 

This means, for example, you can 
have multiple geometry editors, 2D 
paint sessions, 3D paint sessions, and 
UV mapping windows open simultane- 
ously. In each geometry window, how- 
ever, you control what is visible vs. 
what is hidden — that is, you can dis- 
play different objects or sets of scene 
objects in different windows, even 
though you're looking through the 
same camera from the same vantage 
point. Having isolated objects and 
groups this way, you could bring up 
one or more 2D and 3D paint windows 
showing the isolated objects. Because 
these editors are linked, as you paint in 
2D it updates both the 3D view and 
any geometry editors. 

This differs from working in an appli- 
cation such as 3D Studio Max, in which 
you can have more than one instance 
of a single viewport, but could not hide 
or show different objects in each one. 
(In Max, you'd achieve isolation with 
additional cameras in the scene; in 
Maya, you'd accomplish a similar result 
by assigning objects to different layers.) 
Mirai operates from a single-camera 
perspective; you look through this cam- 
era at all times. (Additional cameras are 



jeffrey Abouaf is an artist, animator, and instructor who appears at home in a couple 
of institutions in downtown San Francisco. 



planned for a future release.) While you 
will occasionally set the camera to the 
XYZ orthographic views, the traditional 
four-windowed orthographic presenta- 
tion is not the intent. To model and 
animate in Mirai, you see the scene 
through the camera lens's perspective. 
You have a wide choice of lenses, and 
can save multiple viewpoints, animate 
camera motions, and attach the camera 
to a path. 

Mirai is "selection driven" as 
opposed to "tool driven." All 3D pro- 
grams have you select objects, faces, 
edges, or vertices, and then perform 
an operation on them, but generally 
you choose a tool first. In Mirai, your 
selection defines your options to a 
greater degree than in other programs 
— if you click on the geometry view 
while working on the model, you can 
switch to camera mode where all 
actions change your viewpoint, then 
click back on an edge or polygon to 
bring up a menu of everything you 
can do to that face. When you first 
encounter this, you may find it so 
seamless that you inadvertently 
switch from camera mode to object 
editing without warning — quite dis- 
concerting. Also, when you're used to 
manipulators constraining transform 
operations, it's a little awkward trying 
to control manipulations in a perspec- 
tive window. Once you understand 
the orders, however, this is a remark- 
ably fast way to work. 

Although availablefor both IRIX and 
NT, Mirai reflects its IRIX roots. 
N ichi men 's N -World (M irai's predeces- 
sor) was deservedly recognized as a pre- 
mier real-time 3D character animation 
system. This was when most real-time 
developers used the SGI platform 
exclusively. When they ported N -Wo rid 
to Windows NT three years ago, its 
hefty price tag and high -end hardware 
requirements kept it out of the hands 
of all but the most dedicated, well- 
funded game shops. 

M irai's "SGI" style comes through in 
its clean interface, with minimal icons 
and no tool tips; you drive it with left, 
middle, and right mouse clicks, with 
results dependent entirely on sequence 
and context. It supports hot keys, but 
has far too many commands to be 
hot-key driven. This is wonderful for 
the initiated, but will cause consterna- 
tion for newcomers. The good news is 
that Nichimen has anticipated the 
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problem with superior printed and 
online documentation and tutorials. 
You'll save a lot of time and minimize 
frustration if you follow the "Getting 
Started" manual before exploring on 
your own. By the time you're through 
with it, you're comfortably reoriented 
and ready to play. 

ONE HELLUVA MODELER. Because of its 
roots in real-time 3D, Mirai has one of 
the most extensive modeling toolsets 
available. The ability to align and 
bevel vertices, edges, and faces enables 
precise, easy control of any object 
property. In the hands of an experi- 
enced artist, edges are quickly aligned 
to follow a character's head and body 
contours and muscle formations 
("Edge Loops"); when these edges are 
extruded and the mesh area subdivid- 
ed and smoothed, you achieve high 
detail and control that rivals any 
package. Figure 1 demonstrates the 
smooth yet highly detailed work 
achievable in Mirai. 

The 2D and 3D paint modules com- 
plement the extensive materials editor 
and mapping capabilities. Like many 
competing packages, Mirai supports 
UVW mapping parametrically by pro- 
jection and face-mapping. You can 
assign multiple types of mapping 
coordinates (such as planar and spher- 
ical) to the same selection set, and 
you can composite multiple layers of 
materials on a face selection, taking 
advantage of different types of projec- 
tions. In addition, Mirai's painting 
capability allows you to paint over 
any seams that might result where dif- 
ferent mapping coordinates meet. 



Nichimen's 
August 1999 
update to Mirai 
introduced "mag- 
net moves" along 
face normals with 
fall off. This feature 
allows artists to 
model by painting 
surface deforma- 
tions and displace- 
ments. This is 
handy, for exam- 
ple, for painting 
extrusions on edge 
loops to create 
cheekbones, 
brows, and so on, 
or for painting an 
extruded layer of 
clothing or armor 
on a character. 

SUBDIVISION MESH MODELING - NO 
NURBS, B-SPLINES, OR H-SPLINES 
ALLOWED. Because if its real-time 3D 
roots, Nichimen has always been a 
polygonal modeler and never support- 
ed spline technologies. Building on 
the pioneering efforts of Symbolics, 
and boasting a staff whose credits go 
back to 1980'sTron, Mirai's developers 
were among the first to embrace sub- 
division-mesh modeling as their tech- 
nology for delivering smooth, organic 
surfaces, only they followed this 
approach before it became fashion- 
able. They call it "Volume Modeling," 
and the surface the "Derived Surface"; 
it amounts to making a low-resolution 
geometric form, and a reference copy 
with high-resolution smoothing 





FIGURE 2 . Combining Mirai's various animation effects offers naturalistic results 
for complex animation sequences. 



FIGURE 1 . Ttiis character shows off the smooth and highly 
detailed worl< achievable in Mirai. 



applied. Changes to the control vol- 
ume update on the high-resolution 
version. The value, of course, is that 
working with polygons presumes you 
can generate multiple levels of detail 
(LODs) from the same control vol- 
ume, that surface deformations do not 
change the face count, and that poly- 
gons provide the lowest overhead for 
texture mapping. Yet the control vol- 
ume also acts like a lattice deformer, 
in that generating poses or morph tar- 
gets is a very elastic experience. 
FK/IK ANIMATION. Mirai's FK/I K solution 
is to create a stop-motion puppet. 
Rather than keyframing each skeletal 
joint rotation, keyframes are set for 
the entirety, pose to pose. The I K sys- 
tem uses quaternion algorithms simi- 
lar to those used in other packages, 
with a second-pass analysis checking 
for incorrect or I ess-th an -natural 
motion. Whereas other applications 
have skeletal motions dependent 
upon pulling the skeleton along a 
path, Mirai is about altering poses. 
The poses can be set by rotating joints 
and/or by "pinning" bones. This pin- 
ning can be in the nature of "glue" or 
a "tack"; if you glue a left foot and 
pull a right hand, the foot will remain 
in place as long as possible before 
pulling away. If you tack a foot, the 
foot will not move and the hand will 
move until it slips away. The pins can 
be temporary; different bones can be 
pinned or unpinned at different 
frames. 

Second, M irai's skeleton responds to 
"magnet" moves, that is, you can 
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move one bone relative to ^^^W 
another specified bone. 
This allows naturalistic 
squash and stretch. These 
features combine, for 
example, to let the charac- 
ter crouch (magnet move), 
spring upward (pinned 
feet); loop around the 
trapeze (feet unpinned, 
hands pinned), and drop 
into a crouch. The fairy 
sequence in Figure 2 
shows how these work 
together. 

Mirai supports the most 
common motion capture 
formats (such as Acclaim, 
Motion Analysis, and 
Biovision), and can send 
the data out to Nichi men's 
Game Exchange utility. 
Nichi men's current devel- 
opment direction is expanding this 
biomechanical capability. In addition, 
Testarossa (which won an Emmy 
award for its figure skating simula- 
tions for the most recent Winter 
Olympics) has written a set of mo-cap 
plug-in tools for Mirai, designed to 
extract added functionality from the 
data files (for more information, see 
http://www.toolsinmotion.com). 

Finally, Mirai supports full non- 
linear editing of motion and motion 
capture data. For example, you can set 
up a run cycle and loop it (using 
motion capture data or keyframing), 
then add a second layer of dodging 
and weaving obstacles. The two 
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FIGURE 3 . Mirai allows you to stitch two motion sequences 
togettier and retain control ofttie transition. 



motions combine seamlessly into the 
final sequence, but could also be 
taken apart and recycled. Mirai also 
lets you stitch two motion sequences 
together, and gives you full control 
over the transition. Figure 3 shows the 
animation editor set up for a transi- 
tion between two motion clips. Not 
only can you control the speed, num- 
ber of frames, and other characteris- 
tics for the transition, you can layer 
other motions on top of the source 
clips. Further, with M irai's scripting 
capabilities you can call and recom- 
bine additional premade layers or 
scripts to make complex, unique 
results. 



FACIALANIMATION: DISPLACE- 

IMENT EQUALS LIP-SYNCH. 
"Displacement" in Mirai is 
what other packages refer 
to as morphing or blend 
shapes — in each case it's 
isolating a series of facial 
expressions for direct or 
indirect use as morph tar- 
gets in facial animation. 
Mirai has this capability, as 
did N-World before it. The 
documentation shows how 
to set up the displace- 
ments, how to "wire" them 
to sliders, and how to use 
the sliders to generate 
unique expressions. 
Because motion editing 
supports layers and scripts, 
setting up displacements 
for one character implies 
you can adapt these to a 
different characters without starting 
from scratch. Figure 4 shows Bay 
Raitt's Horus character set up for lip- 
synching. Note you can seethe 
smoothed version, the connected low- 
polygon modeling version, and the 
slider-driven animated composite all 
within the working environment, 
together with the graphs and timeline 
pertinent to Horus's speech. 

Figure 5 shows John Feather's G runty 
character, specifically how you would 
set up to animate him in Mirai. The 
facial features have been wired to slid- 
ers in the Animation Mixer, the charac- 
ter's hierarchy is laid out in the Anima- 
tion: Viewer Graph, and we see the 




FIGURE 4 . A character set up for lip-synching. All the 
information pertaining to the character's speech is shown. 



FIGURE 5 . A typical facial animation setup in Mirai, with 
all the relevant information at the user's fingertips. 
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FIGURE 6 . The facial animation results: a high-resolution 
version of the character with four morph targets. 



hierarchy of movements in the Anima- 
tion: Script Graph and the Animation 
Timeline. The results appear in Figure 6 
which shows the smoothed, high-reso- 
lution model of Grunty, together with 
four morph targets. 
PARTICLES, RIGID DYNAMICS, GELATIN, 
AND ROPE. M irai supports both rigid 
and soft-body dynamics, allowing you 
to set up interactions between objects 
such as collision detection, wind, grav- 
ity, and so on. The soft-body dynamics 
include Gelatin and Rope simulations. 
Gelatin is intended to simulatejig- 
gling, as in the belly of a fat man or 
something more exotic/ erotic by the 
heroine/hero. Rope calculates the 
effect of a tire tethered to a tree 
branch, and should be very useful 
where any two objects or characters 
are bound together. The particle sys- 
tem responds not only to forces and 
turbulence, but can work into simula- 
tions as any other object. Further, par- 
ticles can be the built-in standard 
shapes or any geometric shape. 
OUTPUT: COMPOSITING AND LAYERING 
ANIMATION. If M irai has a weakness, it's 
the renderer. To be fair, however, this 
weakness in Mirai simply means that 
the built-in renderer does not rival 
Renderman or Mental Ray 2. This 
review did not pit M irai's renderer 
against the new renderers built into 3D 
Studio Max 3 and Maya 2, but it cer- 



tainly measures up 
to the renderer 
included in the 
first releases of 
these competitors, 
and exceeds the 
quality of many 
other packages. 
Like the best of the 
renderers, M irai's is 
multi-threaded. 
For the profession- 
als, Mirai will be 
adapted to work 
with Renderman 
on IRIX and NT by 
year's end. 

You can render 
to stills, play them 
back in real time, 
and/or compile 
them into a movie. 
Mirai includes 
compositing tools 
for layering anima- 
tion and combin- 
ing work with live-action output, 
titling, and the like. While the post-pro- 
duction tools are not nearly as extensive 
as the modeling tools, and lack the 
state-of-theart reflected in its FK/IK, 
M irai's output tools reflect the fact that 
this product has earned a place in both 
cinematic and real-time 3D production. 
CONCLUSION. Nichimen held its first 
annual M irai user meeting at Siggraph 
'99. While I was not surprised to see 
several hundred show up, I was sur- 
prised at how many were serious game 
artists (averaging ten years' experience). 
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many of whom have been devotees of 
the competing high-end 3D modeling/ 
animation packages, who said they had 
switched to M irai for character anima- 
tion production, or would be soon. The 
consensus among the faithful was that 
Mirai's FK/IK capabilities are at least 
one generation ahead of the competi- 
tion. When I brought this up with the 
many representatives of competitors at 
the show, they made it clear they're 
watching Mirai. 

M i rai i s a sol i d, versati I e package 
with cutting-edge character animation 
capabilities. With its highly evolved 
FK/IK, biomechanics, and facial ani- 
mation capabilities, it's ready for 
mainstream use in games and all real- 
time 3D. But to limit it to this niche is 
to underplay its full capability, 
because the modeling, texturing, 
painting, and dynamics properties 
make it as viable for prerendered use, 
and compatibility with Pixar's Render- 
man targeted for year's end can only 
enhance that. The obstacles facing 
M irai's entry into the production 
pipeline appear to have little to do 
with the product, because it looks able 
to compete with the best. Building a 
large user base and replacing existing 
production systems will prove the 
biggest barriers. 

Acknowledgements 

Special thanks to Intergraph Computer 
Systems for use of a TDZ workstation, and 
to sDlabs for their GVXi card used to test 
Mirai. No virtual humans were damaged 
in the course of preparing this article. 



^Nichimen Graphics 

Los Angeles, Calif. 
310-577-0500 
I http://www.nichimen.com 

Price: $6,495. Nichimen 
also offers a 90 percent 
educational discount. 

System Requirements: 

Windows NT 4.0 or SGI 
IRIX 6.3. Both operating 
systems require 128IVIB 
RAM, 300IVIB disk space, 
300IVIB virtual memory, 
three-button mouse. 
Windows requires 
266IVIHZ Pentium II plus 
OpenGL accelerator. 



Pros: 

1. "3D operating system" 
interface enables multi- 
ple windows of the same 
type, revealing/hiding 
different objects, and 
hot-linking to other mod- 
ules such as paint. 

2. Intelligent IK/FK system 
is very easy to use in 
final animation. 

3. Motion capture and 
motion layering; sophis- 
ticated support for main 
motion capture systems. 



Cons: 

1. NT users may have diffi- 
culty with IRIX-inspired 
interface. 

2. Rendering engine as it is 
now is adequate, but not 
world-class. 

3. Needs larger user base 
before cross-user sup- 
port and third-party 
plug-in development get 
fully underway. 
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A Clean Start: Washing Away 
the Millennium 




he millennium is coming to a close at the end of the month. While I 
actually believe that the tum of the century is a year from now, I am 
going to fight it no longer. TheY2K hype has washed away any chance 
of restraining thefeeling that something big is about to happen. 



I for my part am going to toast the 
new millennium next year, but who 
wants to miss out on the big party? 
Let's make it a yearlong celebration. 
What the hell, it only happens once 
every thousand years — I'm going to 
enjoy it. 

For the doomsdayers, it's going to 
be a year of hunkering down in their 
battery-powered shelters, 
hoarding food, waiting for 
everything technological to 
spiral out of control. Many 
will be nostalgic for the grand 
old days of mechanical cash 
registers and supermarket 
checkers who knew the actual 
prices. However, I look for- 
ward to the new year. I I ike all 
things tech ie and don't really 
care if they get the date wrong. 
To quote Douglas Adams, I 
still think digital watches are a 
pretty neat idea. The year 2000 
is going to be full of exciting 
new toys for game developers 
to play with. 

In fact, if you watch the 
news you'll know that game 
developers are going to get 
equipment so sophisticated 
that the government considers 
them weapons. This will be the first 
year that we create games for home 
machines that can perform more than 
two billion operations per second. 
Some of the press I 've read said that 
developers aren't ready to handle that 
much power. I don't know what 
sources they have been talking to. I 
have never met any developers who 
didn't think they could use more 
power even on their current projects. 



Hype and Demos 



That brings me to something that I 
find annoying in the industry. 
News in the high-tech business seems 
to surf hype waves constantly. Nothing 
gets any press unless it has "never 
before been seen on a game console!" 
or is "unlike anything ever created in a 




computer game!" These quotes general- 
ly come from very early views of tech- 
nology demos or art tests. Any evi- 
dence of game play or i nteracti ve 
experience is completely missing. 

Game companies realize this so a 
great deal of effort is spent just com- 



ing up with the technology. A flashy 
demo can get them press coverage, 
attention from publishers, and that 
intangible "hype" from the gaming 
public. Some of this forms the back- 
bone of a healthy development cycle. 
However, when the game engine is 
directing the development of the 
game, priorities are out of whack. 
Most gamers fondly recall 
games that lacked flashy tech- 
nology yet captured their souls 
for hours. 

When it became public that 
Quake 3: Arena would support 
a form of curved surface geom- 
etry, suddenly this became the 
must-have feature for 3D 
action games. Games were con- 
sidered to be using "old" tech- 
nology if their engine didn't 
support curved surfaces. This 
happened regardless of 
whether the game had envi- 
ronments that would benefit 
from curves. Programmers had 
to go back and retrofit their 
engines with some kind of 
parametric surfaces. Level 
designers had to go back and 
invent places that would bene- 
fit from some kind of curves. 
Didn't matter what they were or 
where they were used, just as long as 
it could be added to the feature list. 

It should be clear to anyone who has 
read thiscolumn before that I believe 
technology can be a strong force in cre- 
ating a more compelling gameexperi- 



W hether he's testing thetheories of water displacement whilescuba diving or in the 
tub with his duckie, you can drop jeff a Iineatjeffl@darwin3d.com. 
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ence. However, technology should not 
be turned into a checklist and become 
the only determination for a game's 
potential for success. The game is what 
is important. Thetechnology isjust a 
vehicle to enhance the experience for 
the player. 

At E3 this year, I was amazed at the 
Playstation 2's reception. There we 
were at a show filled with amazing 
games for all platforms. Real-time 3D 
graphics were represented everywhere. 
Th e I evel of art was u n bel i evabi e. 
Game play and production on every 
platform from PC to Game Boy were 
very impressive. But what was the 
"buzz" in the press? The Playstation 2 
demos. The Playstation 2 is going to 
revolutionize gaming. Games will 



LISTING 1 . Processing the height field. 



never be the same. What interactive 
demo was shown that elicited these 
opinions? Some footage of a car dri- 
ving through a scene and a duck in a 
tub of water. 

Sure, it was a beautiful car and a cool 
duck. However, it wasjust a display of 
technology and computing power. 

Don't get me wrong. I am certain the 
Playstation 2 will bean amazing con- 
sole. The hardware looks impressive. 
Sony has definitely proved they can 
foster the creation of great games and 
lots of them. They also wanted to build 
up momentum for the new console, 
and I think they succeeded. They rec- 
ognized that technology can be used to 
build hype and anticipation without 
even having a game. 



///////////////////////////////////////////////////////////////////////////////////// 
// Procedure: ProcessWater 

// Purpose: Calculate new values for the water height field 

///////////////////////////////////////////////////////////////////////////////////// 
void CAguaDlg: :ProcessWater() 
{ 

//// Local Variables 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
int ij; 
float value; 

///////////////////////////////////////////////////////////////////////////////////// 
for (j = 2; j < WATER.SIZE - 2; j++) 
{ 

for (i = 2; i < WATER.SIZE - 2; i++) 
{ 

// Sample a "circle" around the center point 

value = (float) ( 

READBUFFER(m_ReadBuffer,i-2,j) + 
READBUFFER(m_ReadBuffer,i+2,j) + 
READBUFFER(m_ReadBuffer,i,j-2) + 
READBUFFER(m_ReadBuffer,i,j+2) + 
READBUFFER(m_ReadBuffer,i-l,j) + 
READBUFFER(m_ReadBuffer,i+l,j) + 
READBUFFER(m_ReadBuffer,i,j-l) + 
READBUFFER(m_ReadBuffer,i,j+l) + 
READBUFFER(m_ReadBuffer,i-l,j-l) + 
READBUFFER(m_ReadBuffer,i+l,j-l) + 
READBUFFER(m_ReadBuffer,i-l,j+l) + 
READBUFFER(m_ReadBuffer,i+l,j+l)); 

value /= 6.0f ; // Average * 2 

value -= (float)READBUFFER(m_WriteBuffer,i,j); 

// Values for damping from 0.04 - 0.0001 look pretty good 

value -= (value * m.DampingFactor) ; 

SETBUFFER(m_WriteBuf f er ,i, j , (int) value) ; 

} 

} 

SetDisplayO; // Draw and Swap Buffers 

} 



Yes, I Have a Point 

■ want people to realize that technolo- 
gy isjust a meansfor achieving a 
result. I hope to discuss techniques that 
make you th i n k about ways you can 
attack a particular problem. Hopefully, 
these ideas can be used on a variety of 
platforms in a variety of ways. 

For example, let's take the water 
effect from the Playstation 2. 1 think 
one of the reasons it was so i mpressi ve 
i s th at water i s terri bl y d i f f i cu 1 1 to rep- 
resent in a real-time 3D simulation. It 
remains hard even for the visual effects 
community. They have unlimited poly- 
gon budgets yet modelers will still 
groan if you ask for realistic water. In 
the early days of real-time 3D games 
(what was that, I ike three years ago?), 
polygons were at a premium. You 
could not represent water with lots of 
geometry so developers had to create 
animated textures that showed nice 
rippling water. It was still pretty life- 
less. It could not react to what was 
going on around it and sort of just did 
itsown thing. 

However, with all thebillionsof oper- 
ations per second the new millennium 
will offer to developers, we can do bet- 
ter. You probably have seen waterlike 
ripples as Java web site banners. The 
effect has been around for years and is 
quite simple. It does a good job of simu- 
lating how ripples will interact with 
each other and reflect off barriers. Since 
it can be created in Java, it's obviously 
not too complex, either. 
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In fact, theeffect isreallyjust aform of image processing. 
Start by creating a double-buffered height array that will hold 
the values for the water level at each position in thegrid.The 
key to making this array behave I ike water is to determine the 
new level at each location. This is done by sampling the sur- 
rounding locationsto determine whether the current location 
should be moving up or down. I chose to samplearough cir- 
cle around the center point as you can see in Figure 1. 

If I wanted to average the water levels over this region, I 
would add the values together and divide by 12. However, 
th i s i s wh ere we are go i n g to fake some of th e f I u i d dy n am- 
icsthat make this look like water. Water level actually rises 
when the surrounding pressure is increased. Think of 
squeezing water in a plastic bottle and watching the water 
in the center rise. So, I can think of the water level at each 
location as representing the water pressure. When the 
water level surrounding a 
location is high, that has the 
effect of raising the water 
level at the center above the 
surrounding locations. Like- 
wise, when the surrounding 
level is low, the pressure is 
greatly reduced and the level 
at the center should drop 
below the average. So, 
instead of dividing by 12, I 
divide the sum of the sur- 
rounding levels by six, dou- 
bling th e average h ei gh t . 

In order to give the water 
motion, the height of the cur- 
rent position in the previous 
frame is subtracted from the 
new calculated height. Now 
everything is in motion. How- 
ever, there is no way to reduce 
that motion. I can cause the 
system to lose some energy by 
applying a damping factor 
that is multiplied by the 
change in height. That way, I 
can besurethat the field will 
come to rest if nothing is 
changed manually. The code 
for calculating the water level 
is in Listing 1. To get things 
started, I simply write some 
values directly into the height 
array and let it run. 




scheme. This image ends up looking likea bump map. You 
can see what it looks like to convert the height array into an 
image in Figure 2. 

This creates a pretty good texture that could be used in a 
3D environment to simulate a pool or fountain. However, I 
can make it even more interesting by applying some envi- 
ronment mapping techniques. Thegradient of thewater lev- 
els surrounding a location can be used to define "normals" 
like you would find on a 3D mesh. I could then trace these 
normals to see where they intersect my environment map. 
However, an even faster way is to treat these gradients as off- 
sets into the environment map. At position (u,v) in the 
Height array: 

offsetX = height_array(u + 1, v) - height_array(u - 1, v); 
offsetY = height_array(u, v + 1) - height_array(u, v - 1); 
sourceTexel = (u + offsetX, v + offsetY); 

This can be blended with 
the height color to create a 
shaded reflection, as you can 
see in Figure 3. However, this 
kind of blending is processor- 
intensive. But, since I eventu- 
ally want to use this in a real- 
time 3D environment, why 
not make use of my graphics 
card? 



Hardware Help 



FIGURE 2. A water image. 



Viewing the Water 

■ now have a height array 
that animates in a way that 
forms ripples and wakes. I can 
easily turn that height field 
into an image and display it 
by converting the values to 
grayscale or to some color 




FIGURE 3 . Environment mapping and stiading. 



I have a nice 3D graphics 
card that can blend two tex- 
tures together without involv- 
ing the CPU. To make this 
work with my textures, the 
environment map calculations 
set the UV coordinates for the 
environment map pass. Most 
of the graphics hardware that 
is currently popular with game 
players can blend two textures 
together in a single pass. This 
means that if your hardware 
can handle it, the blending of 
the environment map and 
bump map are rendered at 
once. 

Once hardware is in charge 
of the blend, it's easy to con- 
trol theamount each image 
contributes to thefinal render 
by using the alpha values. I 
can also take advantage of the 
built-in filtering to smooth 
out the fact that my maps are 
of relatively low resolution 
(say, 128x128). 

I can also use the informa- 
tion I now have to make the 
scene even more immersive. 
Water consisting of a single 
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flat polygon looks strange no matter 
how interesting the animated texture 
looks. However, I could create the sur- 
face on the same grid as the height 
array. If my height array is 128x128, 1 
can create a polygonal grid that is also 
128x128. 1 then use the data in the 
h ei gh t array to d i sp I ace the vert i ces 
in the water mesh. Now, when the 
water ripples, the texture not only 
changes, but the actual surface of the 
water moves also. This all combines to 
create a very realistic looking water 
simulation. 

Best of all, there are built-in perfor- 
mance adjustments to make sure it 
runs well on all sorts of systems. If the 
player doesn't have fast 3D hardware 
you can use a lower resolution for the 
displacement mesh. If the CPU is older, 
lower the resolution in the original 
height array. You can also turn off the 
environment map if fill rate is an issue. 
If the player has a really nice system, 
all features are set at the highest resolu- 
tion. This kind of detail adjustment is 
critical as the number of possible user 
configurations increases. 

Improving the Accuracy 

If I generated actual normals, I could 
improvethelooka bit. For one 
thing, I could simulate the light diffrac- 
tion through water. I could then create 
another environment map represent- 
ing the reflection, which is underneath 
the water. I'm not sure that it would 
look any better than the environment 



map hack I already 
described. However, 
actually using the 
normals to generate 
the map for the 
reflection makes 
some sense. Real 
environment maps 
are view-dependent 
and require the nor- 
mals for calculation. 
The next generation 
of graphics cards 
coming out this year 
support cubic envi- 
ronment mapping. 
That will enable 
effects such as water 
reflection to be cal- 
culated more easily. 
I saw another 
effect recently that really adds to the 
realism of rendering water. Nvidia has 
been showing a demonstration of 
Fresnel Reflections where they create a 
completely variable reflection based on 
the viewing angle. It produces a much 
more accurate reflection image at the 
cost of extra CPU calculations. They 
may have some information on their 
web site about the technique by now. 

Considering the actual physics of 
the water itself, the method I described 
here is completely inaccurate. There is 
no physical simulation of water hap- 
pen i ng at al I . Li ke many game pro- 
gramming methods, tricks are used to 
achieve the desired look without the 
complex calculations. 

These days, however, it's worth con- 
sidering designating more CPU power 
for methods that increase the dynamic 
realism in the scene. When I wrote the 
column on mass-and-spring systems 
for cloth animation ("Devil in the 
Blue Faceted Dress: Real -Time Cloth 
Animation," May 1999), it may have 
occurred to you that a spring system 
could be made to behave like water. 
Each element in the mesh could be 
restricted to move only up and down 
and each element is connected to its 
neighbors by springs. You can see this 
in Figure4. 

However, even this method differs 
from the way actual water performs in 
several ways. One key difference is the 
way true water behaves when com- 
pressed. The total volume of the water 
should be preserved. If I compress the 
water on one side, the level should 



respond by rising on theother side. 
Also, the methods I have discussed do 
not account for what is in the water. I 
am interested in simulating the actual 
flow of thewater. It should beableto 
spill across a terrain as well as form 
eddies and standing waves. Also, a 
height field naturally makes effects such 
as breaking waves or splashes that flow 
over into adjacent cells impossible. To 
get these kinds of interactions, I need to 
makethesimulation more complex. I 
will have to look towards the field of 
computational fluid dynamics (CFD). 
Perhapstherearesome lessons in that 
field for game developers. 

But that will have to wait until next 
time. For now, play around with the 
simple image processing method for 
water. It is easy enough to understand 
and you can quickly experiment with a 
variety of effects. ■ 

The image-based water effect has been 
kicking around so long, I don't l<now 
where it originated. I see it crop up on 
Internet forums every couple of months. 
A quick pass over the search engines 
yielded quite a few linl<s: 

• http://www.remedy.fi/company/ 
cool_stuff_data/stonei.shtml 

A Java-based applet implementing 
something similar to what I described. 

• http://freespace.virgin.net/ 
hugo.elias/graphics/x_water.htm 
Hugo Elias has a little bit of every- 
thing on his site. The section describ- 
ing the water effect is pretty thorough, 
complete with a sample application. 

Also check out: 

• Fournier, Alain, and William Reeves. 
"A Simple Model of Ocean Waves." 
Siggraph 1986, Vol. 20, No. 4, pp. 
75-84. 

/ didn't tall< about generating wave 
motion via simple trigonometric func- 
tions. This paper examines this in 
depth. 

• Kass, Michael, and Gavin Miller. 
"Rapid, Stable, Fluid Dynamics for 
Computer Graphics," Siggraph 1990, 
Vol. 24, No. 4, pp. 49-55. 

If you want to read ahead and learn 
about real-time methods for CFD, 
checl< this out. 
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No Pain, No Gain: Implementing New 
Art Technology in Quake 3: Arena 

hen beginning a new project, an immediate question tliat comes 
to developers' minds is, "Are we going to use the same technolo- 
gy or an entirely a new game engine?" A question that pops up 
for the artist in particular is/'Do I upgrade to the next version of 



ARTIST'S VIEW 



mated in Alias|Wavefront's Power Ani- 
mator. The reason I went with Alias is 
because fellow artist and id co-owner 
Kevin Cloud had been using it since 
Quake and already integrated it into 
the production pipeline. Recombined 
by Carmack's wizardry, the game 
engine animated characters in the 
game via vertex deformation using a 
string of .TRI files exported from Alias 
as basic, linearly interpolated key- 
frames. Each animation cycle — walks, 
runs, deaths, and so on — were stored 
as separate f i I es th at cou I d be accessed 
and re-exported to .TRI files whenever 
we wanted. Of course, the immediate 
problem that comes to mind when 
creating models and animations this 
way is that when any changes are 
made, a plethora 
of files must be 
tweaked and re- 
exported — very 
painful, trust me. 

Si nee the ques- 
tion of utilizing 
new technology for 
a new project is 
moot at id 
(Carmack always 
retools or recreates 




the head and upper body, and would 
give me more flexibility to create bet- 
ter animations at a higher polygon- 
per-model budget. This system also 
enabled more realistic and sponta- 
neous animations, since the lower and 
upper body animations were complete- 
ly detached and unrelated unless 
explicitly specified otherwise. 

For me, the new animation system 
meant I could consolidatetheanima- 
t i on s f r a si n gl e ch aracter i n to n e 
file. This in essence rendered the ani- 
mation file for a character in Q3A a 
"folder" in which sequences are like 
pages th at th e en gi n e ref eren ces wh en 
an i mati ng the game's characters. 
Making changes to the model became a 
lot easier, to say the least. Another 

advantage of keep- 
ing theanimations 
in one file was that 
it allowed me to 
utilize a great fea- 
ture of Character 
Studio: sharing .BIP 
files. Character 
Studio's ability to 
stream different 
animations togeth- 
er via its Flow 



my art tools or stay where I am?" 
While the answer to thefirst question 
often varies, the answer to the second 
shouldn't. 

Spending more than a year or two 
working on a game means that the 
toolsyou started with have invariably 
evolved into their next version or iter- 
ation by thetimeyou have finished. 
Unless you've switched mid-project, 
you have to take the time at the end of 
a project to learn the new tools— that 
is, if you're given the time to train and 
the upgrade of the product itself. 



Changes from Q2 to Q3A 

hen we completed Quake 2 at 
the end of 1997, we started in 
on our next project. Quake 3: Arena. 
For id, this new project introduced a 
dramatic departure from the usual first- 
person shooter formula. Instead of hav- 
ing players opposing a horde of blood- 
thirsty monsters while struggling to 
figure out puzzles and find keys that 
would allow them to escape a 
labyrinthine maze. Quake 3: Arena 
would be all about deathmatch. Gone 
was any sort of suspense or story-dri- 
ven tension. Instead, the game was 
about combat and competition — play- 
ers pitted against other human oppo- 
nents or complex, artificially intelli- 
gent bots via a LAN or the Internet. 

During Quake 2, 1 modeled in 
Kinetix's3D Studio R4 (DOS) and ani- 



the game engine for 
new projects), it came as no surprise 
when John announced the implemen- 
tation of a new animation system for 
Q3A. The new "tag" system would save 
storage space by using a single triangle 
to represent certain body parts such as 



Manager was one of 
the primary reasons I chose M ax after 
Q2 instead of Maya, Softimage, Light- 
wave, Nichimen, or any other program. 
Sharing animation data is so important 
because, in a crunch, I can simply plug 
one character's animation data into 



w 



Paul Steed is a Guy. He likes Guy things: working out, playing pool, drinking beer, and trying hard to stay out of trouble. He happens to 
make art for computer games and occasionally convinces learned editors he's a competent enough writer to contribute to their esteemed 
publications. W rite him at psteed@idsoftware.com if you're bored. Contrary to popular belief, there's no such thing as too much e-mail. 
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FIGURE 2 . To combat characters sliding around in 
place wtiile turning, a "stiuffle" was added to give ttiem 
somettiing else to do witti ttieirfeet. 



another and make tweaks instead of 
having to animate 40 characters 
entirely from scratch. This worked 
only because the sequence of all the 
character's animations had to be the 
same (for example, three death anima- 
tions, then gestures, then walks, then 
runs, and so on). The length and style 
of animations could vary from charac- 
ter to character, but the basic order 
had to remain the same due to the 
new animation code. 



Match Tag "A" with Tag "B" 

In Quake 2, each frame of animation 
I exported served as a keyframe for 
th e en gi n e to i n terpol ate th e posi t i on 
of the mesh's vert ices linearly to the 
next saved animation frame. Although 
the frame rate was only 10 frames per 
second, some characters had up to 500 
frames of animation to support — not 
only, say, firing a weapon, but firing a 
weapon whilestanding and firing a 
weapon while crouched. There were no 
animations of characters firing while 
running or moving, since! couldn't 
anticipate where in their stride they 
would be when attacking. Of course, 
this quickly reveals the I imitations of 
the vertex deformation scheme as the 
character si ides all over the place while 
firing on the move (hence the term 
"skating"), because his body is locked 
in thestationary "firing-while-stand- 
ing" pose. 

Hierarchically, implementing the tag 
system (see Figure 1) meant that the 
lower body would be the parent and 
theupper body thechild (since the 
lower body incorporates locomotion). 
Getting a character into the game went 




something likethis: 
create the character, 
assign the Physique 
modifier to the mesh, 
animate it in a specific 
order of animations 
(both body parts 
together, then upper 
only, then lower), cre- 
ate a small right trian- 
gle with the point fac- 
ing forward, name it 
TAG_TORSO, link it 
(again by assigning 
Physique to it) to the 
point where the biped 
spine rotates, and save 
it. Once! had the file saved I'd delete 
the upper body and export the lower 
body only asa .3DSfile (theengine 
couldn't work with the native M ax file 
format), keeping the tag as a represen- 
tation of theupper body. (It was linked 
to the skeleton/biped, which the 
exporter ignored.) I'd then do the same 
for the upper body. 

This sucked — mainly because of 
having to remember which body part 
to delete, and thefact that after doing it 
for a couple of characters the poor 
artist's mind can get confused. Also, 
once we got the model to show up in 
the game world by converting the .3DS 
files to a game-digestible format, the 
animations weren't quite right. While it 
was cool to move the mouse and see 
the upper torso move with the "free 
look" motion of the mouse, theupper 
body was stiff. Once you passed a 
threshold of 30 degrees or so, the feet 
would stay still while the body rotated 
in place. This rotation (likethesliding 
effect in our previous system) brokethe 
illusion of the character having contact 
with the ground, exhibit- 
ing any sense of weight, 
and itwasgenerally nota 
good thing. So we made 
some changes. 

Instead of deleting any- 
thin g, we j ust kept every- 
thing in onefileand 
m ad e su re t h e d i f f eren t 
body parts adhered to a 
strict naming conven- 
tion. Any file associated 
with theupper body 
would be preceded with a 
"U_" (U_TORSO, U_ARM, 
and so on). Files associat- 
ed with the lower body 



would be preceded with "L_." We also 
determined that the reason the upper 
body still appeared stiff was that peo- 
ple naturally lead turns with their 
heads. So we detached the head, 
necessitating a third naming conven- 
tion ("H_"), as well asa new tag 
(TAG_HEAD). To counter the problem 
of sliding in place while turning, we 
added a "shuffle" where the character 
would pick up his feet and turn pro- 
grammatically (Figure 2). 

This was really no big deal as all ani- 
mations have to be done "in place" for 
bounding-box consideration. (The 
bounding volume of a model created by 
its aggregate vertices equals the area i n 
XYZspacethat registers a hit when fired 
upon.) Another change we decided to 
make was to export th e model s as ASC 1 1 
files instead of .3DS. From the huge 
amount of information contained in an 
ASCII file (or in Max's case, .ASE), the 
programmers could cull all the informa- 
tion they wanted about normals, UVWs, 
and animation data. 

This worked much better. The head 
detachment as yet another layer in the 
tag hierarchy made the motion of the 
character's upper torso correspond 
almost eerily with the movement of the 
mouse. As the mouse moved, the head 
would move just barely, and then the 
torso, and then the character would 
raise and lower his feet as he turned in 
place to look where the mouse was 
telling him to look. Of course, thedraw- 
backto this was that facial expressions 
and any sort of hair animations went 
out the window. Still, the in-game an i- 
mationsdidn't quitejibe with how I 
wanted them to look and definitely dif- 
fered from an orientation standpoint 
from their Max file counterparts. 



FIGURE 1 . Mesh, si<in, and Character Studio biped 
with proper tag placement. 
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FIGURE 3 . Hours of consternation over inappropriate sliearing could tiave been 
avoided by turning off the animation tags' Inherit Scale at the start. 



Jane! Stop This Crazy Thing 



After some research, it became clear 
to me why the animations were 
off — it was the stupid tag. I had been 
I i n ki n g th e TAG_TO RSO to th e to rso of 
the skeleton or biped (first spine link). 
This was wrong. I was supposed to be 
linking it to the pelvis. (I was confused 
— sue me.) I also misunderstood the 
fact t h at t h e base oftherighttriangle 
of the tag was the exact point at which 
the rotation needed to occur (not the 
overall area of the triangle as I had 
thought). 

After I got that straight, things looked 
better, but if the pelvis rotated at all or 
was oth erwi se movi n g i n appropri atel y , 
the torso of course did its animations 
from whatever position the sometimes 
errant tag told it to. Si nee the tag repre- 
sents the upper body's position relative 
to its predefined default position (asin- 
gleframein theanimation set), rotating 
the tag itself during the animations 
would rotate the base at which the 
upper body was attached. So, happy 
with this second level of "after market" 
animation capability, I went and started 
rotating the tag so it would always face 



forward. Soon I became frustrated, how- 
ever, because the tag would do this 
weird shearing thing and thetri angle 
would try to skew itself in a seemingly 
random fashion. 

This.. .drove.. .me.. .nuts. 

After all kinds of kludgy, inefficient, 
m i ckey- mo u se attem pts at ban d-ai d i n g 
the problem, I resorted to bugging 
Character Studio's developers and ask- 
ing them for help. After much experi- 



menting and exchanging of e-mails and 
M ax fi I es gal ore, J eff Yates at Ki n eti x 
asked me if I had unchecked a particular 
option in the Hierarchy options of the 
mesh. D'ohh. How the heck was! sup- 
posed to kn w th at? (Th i s seri es of 
check boxes is in the Inherit Scale sub- 
menu of Link Info.) Once! turned the 
Inherit Scale off for the tag (Figure 3), 
the shearing went away and I was 
happy...fora while. 
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Then I noticed 
some other prob- 
lenns with the torso 
nnoving around 
and, clever guy that 
I am, I thought 
about the process 
some more. You see, 
the conversion 
process of .ASE to 
.MD3 (game format) 
happened via strict 
adherence to nam- 
ing convention. 
This basically 

allowed me to have all kinds of props 
with the file and, of course, made the 
converter ignore them along with the 
biped geometry (among other things) 
through "wrong" naming conven- 
tions. Si nee the tag at the torso was 
essentially doubled (according to 
Carmack) as the code separated the 
upper and lower body, why couldn't I 
double the pesky tag, name it some- 
thing besides TAG and use it as refer- 
ence? This way I could see why the 
upper body wasn't seating properly on 
the lower body. 

So that's what I did and, lo and 
behold, there were some discrepancies 
(mainly due to the mostly goofy IK 
solution Character Studio uses for the 
upper body). Utilizing the oft-unsung 
"snap to vertex" power of M ax's Grid 
and Snap Setting dialog box , I adjusted 
the position of the tag and made sure it 
matched my reference tag at the base 
of their respective right triangles. 



This Is Ny Weapon, This Is Ny Gun. 

Having mastered the basic 
mech an i cs of th e n ew tag sys- 
tem it was time (naturally) to make 
some more changes. People com- 
plained about the difficulty of see- 
ing which weapon they held in Q2. 
Mod authors quickly rectified this 
by adding customized code that 
allowed players to see their 
weapons during deathmatch. In 
Q3A, we decided to go ahead and 
implement the multiple weapons, 
but added a "weapon-switch" ani- 
mation . Th i s departed from 
Quake's original instant weapon - 
switch that the diehard fanatics 
were clamoring for even duringQ2 
(Figure 4). 




FIGURE 4 . Quake 2 shotgun (left) vs. Quakes shotgun: animated hands and field 
of-view-compensated geometry give way to no hands and more attention paid to 
the weapon's business end. 



Carmack wanted me to use the same 
animationsfor all weapons (one default 
position, onefiring, and oneweapon- 
switch). I balked, saying I wanted to 
have different positions for each 
weapon so the design wouldn't be dic- 
tated by asinglegrip. Also, how a player 
held a weapon could be noticed from a 
distance and bean additional cuefor 
ordinance recognition. Well, I didn't get 
my way but I did get one extra default 
position for a melee weapon (the 
Gauntlet). This sort of compromise 
occurs all the time when you pit tech- 
no I ogi cal I y-con strai n i n g frugal i ty ( keep- 
ing the memory requirements low 
begets a faster-running game, obviously) 
vs. artistic expression. 

Another artistic hurdle was the fact 
that my programming leader wanted to 
implement the tag system in the 
weapon as wel I . Th i s wou I d save even 
more space and do what we hadn't 
done in Ql or Q2: use the same model 
for both the"in-use" view of the 
weapon and the weapon you see in the 
world. The reason the previous two 




FIGURE 5. The final design for Q3A 's weapons 
also incorporated the animation tag system. 



efforts didn't share 
the same geometry 
for both instances 
of seeing weapons 
was... wel I, I don't 
know. 

The only prob- 
lem with this new 
method of seeing 
the weapons was 
that it added yet 
another shackle to 
the weapon 
design con- 
straints. The field 
of view while playing the game is at 
least 90 degrees (it can be raised if 
desired). While it may not quickly be 
apparent why this is a problem, the dif- 
ficulty lies in how much of the weapon 
you actually see in your view: only the 
end of the barrel. In Quake 2 I used 
animated hands and squished, unique 
geometry to make the weapons in view 
look interesting and, more important- 
ly, to simulate the right perspective. 

So, using mostly artist/owner Adrian 
Carmack'scool designs, I went about 
making weapon models that were equal- 
ly appealing in both the normal view 
and the in-use view. Do I make it cen- 
tered, held to the right, the left, what? 
In the end, I settled on a slightly-to-the- 
right position that corresponded to the 
animation of the characters when they 
changed weapons (see Figures). 

I solved the tag issue by first building 
a weapon that I positioned in the char- 
acter's hands with a comfortably 
aggressive stance, settling on a semi- 
sniper position. I took this first weapon 
and embedded a copy of the tag I used 
for the torso and the head into the 
weapon. The reason for the tag 
attachment was so that I could link 
the weapon to the character's right 
hand (having positioned it correct- 
ly). That way, after I had complet- 
ed the character's animations and 
was ready to export the file, I could 
create a snapshot of the weapon, 
del ete al I verti ces except for th e tri - 
angle, rename it TAG_WEAPON, 
assign Physique to it, link it to the 
right hand, and finally delete the 
original weapon (or keep it under a 
garbage name for reference). 

As far as the commonly held grip 
dictating the design of the weapon, 
I think we ended up with a pretty 
varied arsenal despite the I imita- 
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tion. Once I completed a weapon I just 
placed it over the top of my archetypal 
first weapon (aligning the grips so they 
matched), deleted all thefirst weapon's 
vertices except for the tag again, and 
saved the new weapon off with a tag in 
the exact same position astheonein 
thefirst weapon. Thus, when I went 
through the process of animating and 
exporting weapons, they all had their 
tags in the right place. 



And What About Style? 

Enough about the mundane and 
tedious assimilation/accommoda- 
tion of the technology into the work- 
flow, what did I actually do with it? 
Now that's a great question ! I made 
some pretty cool models (textured by 
the incomparable Kenneth Scott) with 
some pretty cool animations.. .and I had 
to fight for them the entire time. Of 
course, Carmack's minimalist philoso- 
phy towards things such as vertices, 
faces, texture map size, and total frame 
counts was at direct odds with my 
gran d i ose p I an s to create so me h i gh - 
flying, John Woo-style, highly kinetic 



action. Luckily, he's the type of guy 
who, once shown something, can be 
convinced to bend a little for art's sake. 

A good example of this was my hell- 
bent desire to have swimming anima- 
tions in the game. Why do we need 
swimming? he'd ask. Because it'll look 
cool, was my reply. Sure enough, 
Carmack — doubtful yet accommodat- 
ing — put theswim animation in and 
everyone went "Ahhh..." or "Ooooh..." 
H e became a bel i ever. 

An oth er case was th e j u m p an i ma- 
tions. I was given one paltry frame to 
represent a recovery from jumping for- 
ward or backward (two separate anima- 
tions). Characters in our gamejump the 
equivalent of 20 feet in the air — cer- 
tainly they needed to be able to recover 
from that kind of air time. So I used up 
five to ten frames for recovery, and it 
turned out much better. 

And si nee there were two kinds of 
jumps, I decided to differentiate the 
backward one by making the character 
do a back flip ashejumped. Who cares 
that your view doesn't change during 
th e fl i p? Th i s i s a fi rst-person game, 
remember? Everything about your char- 
acter is done for the enjoyment and 



benefit of your opponents. Why not 
give them a show? 



The Moral of the Story 

The character animation technolo- 
gy was but one of several changes 
we made for the art in Quake 3: Arena. 
In fact, even though it's a Quake prod- 
uct, Q3A's code shares simi larities with 
its esteemed predecessors strictly by 
virtue that it's 3D and from id Soft- 
ware. Carmack was continually refin- 
ing and optimizing the technology in 
all aspects of the game up until the 
very end of development. 

As for my part in the implementation 
of the animation changes, morelucid 
communication with the programmer 
on some issues would saved me some 
time and trouble. But it took trial and 
error — many, many iterations and 
more than a smidgen of perseverance — 
to make it work. That's what integrating 
new technology is about: sticking it out 
and always trying to find a better solu- 
tion to the problem at hand. That's one 
of th e th i n gs th at makes th i s type of 
work so challenging and rewarding. ■ 
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The Integrated PC: More Consumers 
with Fewer Choices 



t'salways nice to note the surge in demand tliat accompanies tine latest 3D 
grapliics or audio product release. It's a sign of the health of high-end technolo- 
gies, and consumers' insatiable appetite for a better multimedia experience. 
Fash ion able technologies also make it difficult for game developers to predict 



the amount of devotion they should 
lavish on "the next great thing." To 
add to developers' woes, there is the 
current growth in low-cost PC systems, 
in which graphics and audio functions 
are integrated into chipsets in the 
motherboard, and multimedia process- 
es are passed off to more powerful 
CPUs that are left idling until software 
catches up. The question is, are game 
developers reducing their total avail- 
able market (TAM ) by not targeting the 
base level of performance that these 
systems offer? 

Putting It All Together 

Intel isthebigcheese of integration. 
This year, the company formally 
announced that it was getting out of the 
discrete graphics chip business. In other 
words, it wasn't going to makeseparate 
graphics components. Some attributed 
the move to the lackluster performance 
and market share of the company's 740 
graphics chip. Intel has never been shy 
to abandon or change tactics, products, 
and initiatives when it sees its core busi- 
ness of selling CPUsthreatened. An 
integrated PC is one in which the graph- 
ics and audio components can be 
thrown into the logic chips that control 
the flow of data from the CPU to memo- 
ry and various controllers. The result is 
fewer components required, and more 
money left on thetablefortheCPU. 

The mainstay of integration for Intel 
is the 810 Whitney chipset and its latest 
update, the 810e. At the heart of the 
810 chipset is a memory controller with 
built-in graphics technology, called the 
82810 graphics memory controller hub 



(GMCH). It'sa long moniker, but in 
short, the graphics portion of the 810 
chipset has integrated hardware motion 
compensation for software DVD video, 
as well as a digital video output port 
enabling connections to a traditional 
television or flat-panel display. There is 
also an integrated Audio 
Codec 97 (AC -97) con- 
tro 1 1 er th at al I o ws software 
audio and modem func- 
tionality using the host 
CPU. There's a lot more 
electronics than that, but 
suffice it to say that there 
is a measure of 2D, 3D, 
and audio functionality 
built into the chipset that 
helps negate the need for 
extra peripherals— or so 
thethinking goes. 

The810e is aimed at the 
market for Pentium II and 
Pentium III chips, while 
the original 810 is aimed at 
the Celeron and Pentium 
1 1 markets. The basic differ- 
ences between the various 
flavors of the 810 are the 
amount of cache memory 
they allow, as well the way 
they interface to the PCI 
and IDE buses. As you go 
higher up thefood chain, 
the graphics improve, the 
PCI slots are more numer- 
ous, and the bus perfor- 
mance gets faster. 






FIGURE 1: Inters 
overview of how its 
integrated products 
fit in to ttie PC mar- 
l<et, by price segment. 



Integration s Impact on the Market 

Intel isn't the only game in town, but 
its road map and gentle guidance, if 
you will, determine which way the PC 
industry goes. NeoMagic, a maker of 
graphics chips for laptops, has been 
creating integrated parts 
for sometime, but in the 
desktop space there are 
companies such as Silicon 
Integrated Systems ( Si S), 
Via, and a host of graphics 
chip vendors who all have 
the same idea for the low- 
cost PC market. There are 
no hard and fast rules 
about what integration 
means though, and the 
breadth of offeri ngs will 
probably end up being a 
very confusing jumble of 
features. For instance, the 
Si S 620 ch i pset doesn 't 
have all the features of the 
810 (such asAC-97 sup- 
port) and it is primarily 
appearing in very low-cost 
corporate PCs. What may 
be interesting down the 
road is something such as 
the Aladdin TNT2, a col- 
laborative effort between 
Acer Laboratories Inc. 
(ALi) and Nvidia. Intel 
used the core graphics 
technologies of its 740 
chipset, but Nvidia is look- 
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FIGURE 2 . Shipments of integrated parts in clesl<top PCs in millions of units 
(source: Mercury Researcti). 



FIGURE 3 . Breal<down of integrated 
systems deployed by marl<et seg- 
ment (source: Mercury Researcti). 
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ing to bring an altogether different 
level of performance to the low-cost PC 
market. And they aren't the only ones. 

I ntel 's W h i tney ch i pset hoi ds about 
80 percent of the market, according to 
Dean McCarron, principal analyst at 
Mercury Research, and provides graph- 
ics performance on par with a M atrox 
G200, or a little better than an ATI Rage 
Pro. The market for these products is 
sti 1 1 too youn g to j udge the i mpact of 
integrated technologies, but Figures 1 
and 2 may put things in perspective. 

Obviously, the data suggest that inte- 
grated systems are going to take a sig- 
nificant si ice of the PC market. In the 
consumer space, the primary market is 
for Internet-ready, low-cost PCs. The 
good news is that these types of PCs are 
attracting first-time PC buyers, very 
similar to the way the iMac has also 
drawn in a new crowd of computer 
users. These newcomers are going to 
want to do everything else their com- 
puters offer, including play games. 

There is another dynamic of the inte- 
grated PC market that game developers 
might find interesting. According to 
McCarron, more audio add-ons are 
going into the consumer market than 
PCs sold. These add-ons are primarily 
high-end audio upgrades and 3D posi- 
tional audio products such as Creative 
Labs' SoundBlaster Live! card. How- 
ever, this is not yet happening on the 
graphics side, though it may still be too 
early to tell. On 810 motherboards you 
can't even get a graphics upgrade, and 
there is every indication that PC mak- 
ers are finding it easier to upgrade their 
integrated-systems buyer to better 
quality audio than graphics. 



So Where Does That Leave the Game 
Developer? 

Integrated PCs are not going away. 
They are an expanding market and a 
very hot growth area for the PC indus- 
try. By ignoring this market, developers 
arereducing their TAM, which may be a 
conscious creative choice. After all, 
some may not be happy compromising 
the qual ity of thei r game graph ics and 
audio. In time, it will certainly bea sup- 
port issue for game developers because 
games are getting more sophisticated in 
their technology, not less so. 

However, there is a new demographic 
enteri ng the market as a result of these 
lower-cost integrated machine sales, the 
kind of user that can be lumped under 
the heading of mass market. The game 
industry doesn't quite understand the 
mass market yet, a fact quite evident by 
the seemingly endless parade of Deer 
HuNTERknockoffs. It will bea while 
before the game industry figures out 
how to target a user base that is highly 
motivated by the Internet, and less san- 
guine about traditional gaming. Further- 
more, this is a demographic that is 
being weaned on low-cost hardware and 
budget software. 

Thereisalso a unique bundling 
opportunity for the game industry. The 
low-cost PC isgoing out with fewer 
new software titles in some cases, but 
often with a greater number of older 
titles. As such, it may bean ideal mar- 
ket for resurrecting the overall OEM 
market for games. In the past, I have 
addressed the OEM opportunities asso- 
ciated with the high end of the PC 
market, where games eat up the most 




CPU cycles and are sometimes the only 
justification for a powerful new system. 
The low-end users in the PC market, on 
the other hand, are more likely to be 
attracted by a bundle's value because of 
their price sensitivity. PC makers are 
beginning to realize that they need to 
sell their systems on more than just 
Ml PS and hardware configurations. In 
short, there is a growing opportunity 
offered by integrated systems, but it 
comes at the price of a step back, cer- 
tainly in graphics technology, and to 
some extent in audio technology, too. 
There is an opportunity for the game 
industry to increase its TAM , develop 
new OEM relationships, and bring new 
consumers into its fold. What remains 
to bedoneisto acquire a clear under- 
standing of this demographic. That 
may not come for sometime. 

I am reminded of early days of the 
multimedia PC business, when hard- 
ware and software vendors misunder- 
stood the needs of a market in which 
consumers were grabbing CD-ROM 
upgrade kits at $500 a pop, and bring- 
ing home $2,000 PCs by the cartload. 
The result was a mountain of useless 
multimedia CDs, and a crash in the 
price of some multimedia peripherals. 
The hardware and software industries 
need to do a better job with this new 
batch of consumers, and it all starts 
online. AOL is using Compuserve 
memberships and $400 rebates on con- 
sumer PCs to attract new users, and it 
seems to be working. The game indus- 
try needs to come up with new busi- 
ness models to deal with the mass mar- 
ket, or it may just end up being a 
passing fancy as well. ■ 
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Fortunately, the game had some 
things in it we liked. We set up a small 
group of people to take every silly idea, 
every cool trick, everything interesting 
that existed in any kind of working 
state somewhere in the game and put 
them into a single prototype level. 
When the level started to get fun, they 
added more variations of the fun 
things. If an idea wasn't fun, they cut 



side the player's control . If the players 
are in the mood for more action, all 
they need to do is move forward and 
within a few seconds something will 
happen. 

The second theory we came up 
with is the theory of player 
acknowledgment. This means 
that the game world must 
acknowledge players every time 



cabal \ka-'bal\ :to unite in a small party; to promote 
private views and interests by intrigue; to intrigue; to plot. 



it. When they needed a software fea- 
ture, they simplified it until it was 
something that could be written in a 
few days. They all worked together on 
thisonesmall level for a month while 
the rest of us basically did nothing. 
When they were done, we all played it. 
It was great. It was Die Hard meets Evil 
Dead. It was the vision. Itwasgoingto 
be our game. It was huge and scary and 
going to take a lot of work, but after 
seeing it we weren't 
going to be satisfied 
with anything less. 
All that we needed to 
do was to create 
about 100 more lev- 
els that 

were just as fun. No 
problem. 



they perform an action. For exam- 
ple, if they shoot their gun, the 
world needs to acknowledge it 
with something more permanent 
than just a sound — there should 
be some visual evidence that 
they'vejust fired their gun. We 
would have liked to put a hole 
through the wall, but for techni- 
cal and game flow reasons we 
really couldn't do it. Instead we 




Conceptual artwork for a 
ceiling-mounted monster 
tiiat was dangerous to botti 
ttie player and tlie player's 



So, Tell Me About 
Your Childhood 

The second step in 
thepre-cabal 
process was to ana- 
lyze what was fun 
about our prototype 
level. The first theory 
we came up with was 
the theory of "experi- 
ential density" — the amount of 
"things" that happen to and are done 
by the player per unit of time and area 
of a map. Our goal was that, once 
active, the player never had to wait too 
long before the next stimulus, belt 
monster, special effect, plot point, 
action sequence, and so on. Since we 
couldn't really bring all these experi- 
ences to the player (a relentless series 
of them would just get tedious), all 
content is distance based, not time 
based, and no activities are started out- 




Many of our scripted sequences were designed to give ttie 
player game-play clues as well as provide moments of 
slieer terror. 



decided on "decals" — bullet nicks and 
explosion marks on all the surfaces, 
which serve as permanent records of 
the action. This also means that if the 
player pushes on something that 
should bepushable, the object 
shouldn't ignore them, it should move. 
If they whack on something with their 
crowbar that looks like it should break, 
it had better break. If they walk into a 
room with other characters, those char- 
acters should acknowledge them by at 
least looking at them, if not calling out 
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their name. Our basic theory was that if 
the world ignores the player, the player 
won 't care about th e worl d . 

A final theory was that the players 
should always blame themselves for 
failure. If the 
game kills 
them off with 
no warning, 
then players 
blame the 
game and 
start to dislike 
it. But if the 
game hints 
that danger is 
imminent, 
show players a 
way out and 
they die any- 
way, then 
they'll consid- 
er it a failure 
on their part; 
they've let the 
game down 
and they need to try a little harder. 
When they succeed, and the game 
rewards them with a little treat — 
scripted sequence, special effect, and so 
on — they'll feel good about them- 
selves and about the game. 

Secret Societies 

Throughout thefirst 11 months of 
the project we searched for an offi- 
cial "game designer," — someone who 
could show up and make it all come 
together. We looked at hundreds of 
resumes and interviewed a lot of 
promising applicants, but no one we 
looked at had enough of the qualities 
we wanted for us to seriously consider 
them the overall god I ike "game design- 
er" that we were told we needed. In the 
end, we came to theconclusion that 
this ideal person didn't actually exist. 
Instead, we would create our own ideal 
by com bi n i n g th e stren gth s of a cross 
section of the company, putting them 
together in a group we called the 
"Cabal." 

The goal of this group was to create 
a complete document that detailed all 
the levels and described major mon- 
ster interactions, special effects, plot 
devices, and design standards. The 
Cabal was to work out when and how 
every monster, weapon, and NPC was 
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Tips For a Successful Cabal 



Include an expert from every func- 
tional area (programming, art, and so on). 
Arguing over an issue that no one at the 
meeting actually understands is a sure 
way to waste everyone's time. 

Write down everything. 
Brainstorming is fine during the meet- 
ings, but unless it's all written down, your 
best ideas will be forgotten within days. 
The goal is to end up with a document 
that captures as much as is reasonable 
about your game, and more importantly 
answers questions about what people 
need to worl<on. 

Not all ideas are good. These include 
yours. If you have a "great idea" that 
everyone thinl<s is stupid, don't push it. 
The others will also have stupid ideas. If 
you're pushy about yours, they'll be pushy 
about theirs and you're just going to get 
into an impasse. If the idea is really good, 
maybe it's just in the wrong place. Bring it 
up later. You're going to be designing 
about 30 hours of game play; if you really 
want it in it'll probably fit somewhere else. 



Maybe they'll lil<e it next month. 

Only plan for technical things that 
either already worl<, or that you're sure 
will worl< within a reasonable time before 
play testing. Don't count on anything that 
won't be ready until just before you ship. 
Yes, it's fun to dream about cool technol- 
ogy, but there's no point in designing the 
game around elements that may never be 
finished, or not polished enough to ship. 
If it's not going to happen, get rid of it, 
the earlier the better. 

Avoid all one-shot technical ele- 
ments. Anything that requires engineer- 
ing worl< must be used in more than one 
spot in the game. Engineers are really 
slow. It takes them months to get any- 
thing done. If what they do is only used 
once, it's a waste of a limited resource. 
Their main goal should always be to cre- 
ate tools and features that can be used 
everywhere. If they can spend a month 
and make everyone more productive, 
then it's a win. If they spend a week for 
ten seconds of game play, it's a waste. 



to be introduced, what skills we 
expected the player to have, and how 
we were going to teach them those 
skills. As daunting as that sounds, this 
is exactly what we did. We consider 
the Cabal process to have been wildly 
successful, and one of the key reasons 
for Half-Life's success. 

Cabal meetings were semi -structured 
brainstorming sessions usually dedicat- 
ed to a specific area of the game. During 
each session, one person was assigned 
thejob of recording and writing up the 
design, and another was assigned to 
draw pictures explaining the layout and 
other details. A Cabal session would typ- 
ically consist of a few days coming up 
with a mix of high level concepts for the 
given area, as well as specific events that 
sounded fun. 

Once enough ideas were generated, 
they would be reorganized into a rough 
storylineand chronology. Once this 
was all worked out, a description and 
rough sketch of the geometry would be 
created and labeled with all the key 
events and where they should take 
place. We knew what we wanted for 
some areas of the game from the very 
start, but other areas stayed as "out- 
doors" or "something with a big mon- 



ster" for quite some time. Other areas 
were created without a specific spot in 
the game. These designs would sit in 
limbo for a few weeks until either it 
became clear that they weren't going to 
fit, or that perhaps they would make a 
good segue between two other areas. 
Other portions were created to high- 
light a specific technology feature, or 
simply to give the game a reason to 
include a cool piece of geometry that 
had been created during a pre-cabal 
experiment. Oddly enough, when try- 
ing to match these artificial constants, 
we would often create our best work. 
We eventually got into the habit of 
placing a number of unrelated require- 
ments into each area then doing our 
best to come up with a rational way to 
fit them together. Often, by the end of 
thesession we would find that the ini- 
tial idea wasn't nearly as interesting as 
all the pieces we built around it, and 
the structure we had designed to 
explain it actually worked better with- 
out that initial idea. 

During Cabal sessions, everyone con- 
tributed but we found that not every- 
one contributed everyday. The meet- 
ings were grueling, and we came to 
almost expect that about half of the 



group would find themselves sitting 
through two or three meetings with no 
ideas at all, then suddenly see a direc- 
tion that no one else saw and be the 
main contributor for the remainder of 
the week. Why this happened was 
unclear, but it became important to 
have at least five or six people in each 
meeting so that the meetings wouldn't 
stal I out from I ack of i n put. 

The Cabal met four days a week, six 
hours a day for five months straight, 
and then on and off until the end of 
the project. The meetings were only six 
hours a day, because after six hours 
everyone was emotionally and physi- 
cally drained. The people involved 
weren't really able to do any other 
work during that time, other than read 
e-mai I and write up thei r dai ly notes. 

The initial Cabal group consisted of 
three engineers, a level designer, a 
writer, and an animator. This repre- 
sented all themajor groups at Valve 
and all aspects of the project and was 
initially weighted towards people with 
the most product experience (though 
not necessarily game experience). The 
Cabal consisted only of peoplethat 
had actual shipping components in the 
game; there were no dedicated design- 
ers. Every member of the Cabal was 
someone with the responsibility of 
actually doing the work that their 
design specified, or at least had the 
ability to do it if need be. 

The first few months of the Cabal 
process were somewhat nerve wracking 
for those outside the process. It wasn't 
clear that egos could be suppressed 
enough to get anything done, or that a 
vision of the game filtered through a 
large number of people would be any- 
thing other than bland. As it turned 
out, the opposite was true; the people 
involved were tired of working in isola- 
tion and were energized by the collabo- 
rative process, and the resulting 
designs had a consistent level of polish 
and depth that hadn't been seen 
before. 

I nternal ly, once the success of the 
Cabal process was obvious, mini-Cabals 
were formed to come up with answers 
to a variety of design problems. These 
mini-Cabals would typically include 
people most effected by the decision, 
as well as try to in dude people com- 
pletely outside the problem being 
addressed in order to keep a fresh per- 
spective on things. We also kept mem- 
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The team explored a variety of visual 
metaphors that resulted in some very 
unique and effective opponents. 



bership in the initial Cabal somewhat 
flexible and we quickly started to rotate 
people through the process every 
month or so, always including a few 
people from the last time, and always 
making sure we had a cross section of 
the company. This helped to prevent 
burn out, and ensured that everyone 
involved in the process had experience 
using the results of Cabal decisions. 

The final result was a document of 
more than 200 pages detailing every- 
thing in the game from how high but- 
tonsshould be to what time of theday 
it was in any given level. It included 
rough drawings of all thelevels, as well 
as work items listing any new technol- 
ogy, sounds, or animations that those 
levels would require. 

We also ended up assigning one per- 
son to follow the entire story lineand 
to maintain the entire document. With 
a design as large as a 30-hour movie, 
we ended up creating more detail than 
could be dealt with on a casual or part- 
time basis. We found that having a 
professional writer on staff was key to 
this process. Besides being able to add 
personality to all our characters, his 
ability to keep track of thematic struc- 
tures, plot twists, pacing, and consis- 
tency was invaluable. 



Pearls Betore Swine 

By the second month of the Cabal, 
we (the "swine") had enough of 
the game design to begin development 
on several areas. By thethird month, 
we had enough put together to begin 
play testing. 

A play-test session consistsof one out- 
side volunteer (Sierra, our publisher, 
pulled pi ay-testers from local people 
who had sent in product registration 




It's important to include information on the intended path through the level, as 
well as rough geometry and character placement. 



Play-Testing Tips 



Watch your play-testers and let them 
do what they want. If they keep trying to 
do something silly, don't get upset — fig- 
ure out why they want to do it and how to 
accommodate them. We originally added 
breal<able crates to the game simply as a 
technological feature that we wanted to 
show off. There was nothing in them, the 
crates just brol<e. We thought games with 
secrets hidden in crates were lame. After 
the tenth play-tester in a row went through 
and painstaldngly brol<e every single crate 
in the entire game and never got any 
reward but just l<ept doing it (because they 
just l<newifthey just tried long enough 
they'd get the hidden reward) we caved. 
We went back and redesigned levels to 
have crates with goodies in them, and a 
reason to need those goodies. It was a lot 
of worl<, but the remaining play-testers 
were a lot happier. 

Your game is too hard. It just is. 
You're most lil<ely an expert player at the 
game you're developing and it's doubtful 
that there are more than a handful of 
players in the world who are better than 
you. You don't need to care about them, 
you need to care about the 99.9 percent 



of the players who aren't as good as you. 
Some of those players will be really, real- 
ly bad. Tough — they've paid their $50 
and they deserve to be entertained. Mal<e 
the difficult level something you can play 
without too much trouble. Mal<e the easy 
level so easy that you can't imagine any- 
one not being able to win on it. Then, 
mal<e it a bit easier. If you get lucl<y, half 
your players will be able to finish. 




This creature was initially designed 
as a friendly character, but play-test- 
ing revealed players* tendencies to 
shoot first and asl< questions later. 
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cards for other games) play- 
ing the game for two hours. 
Sitting immediately behind 
them would be one person 
from the Cabal session that 
worked on that area of the 
game, as wel I as the level 
designer who was currently 
the "primary" on the level 
being tested. Occasion- 
ally, this would also include 
an engineer if new A! need- 
ed to be tested. 

Other than starting the 
game for them and reset- 
ting it if it crashed, the 
observers from Valve were 
not allowed to say any- 
thing. They had to sit there 
quietly taking notes, and 
were n ot al I owed to gi ve 
any hints or suggestions. 
Nothing is quite so hum- 
bling as being forced to watch in 
silence as some poor play-tester stum- 
bles around your level for 20 minutes, 
unable to figure out the "obvious" 
answer that you now realize is com- 
pletely arbitrary and impossibleto fig- 
ure out. 

This was also a sure way to settle any 
design arguments. It became obvious 
that any personal opinion you had 
given really didn't mean anything, at 
least not until the next play-test ses- 
sion. Just because you were sure some- 
thing was going to be fun didn't make 
it so; the play- 
testers could 
still show up 
and demon- 
strate just how wrong you really were. 

A typical two-hour play-test session 
would result in 100 or so "action 
items" — things that needed to be 
fixed, changed, added, or deleted from 
the game. The first 20 or 30 play-test 
sessions were absolutely critical for 
teaching us as a company what ele- 
ments were fun and what elements 
were not. Over the course of the pro- 
ject we ended up doing more than 200 
play-test sessions, about half of them 
with repeat players. The feed back from 
thesessions was worked back into the 
Cabal process, allowing us to preemp- 
tively remove designs that didn't work 
well, as well aselaborateon designs 
that did. 

Toward the middle of the project, 
oncethe major elements were in place 




Letting players see other characters make mistakes that they'll 
need to avoid is an effective way to explain your puzzles and 
add tension and entertainment value. 



and the game could be played most of 
the way through, it became mostly a 
matter of fine-tuning. To do this, we 
added basic instrumentation to the 
game, automatically recording the 
player's position, health, weapons, 
time, and any major activities such as 
saving the game, dying, being hurt, 
solving a puzzle, fighting a monster, 
and so on. We then took the results 
from a number of sessions and graphed 
them together to find any areas where 
there were problems. These included 
areas where the player spent 




too 
long 
without 
any encoun- 
ters (boring), 
too long with 
too much 
health (too easy), 
too long with too 
little health (too 
hard), all of which 
gave us a good idea as to where they 
were likely to die and which positions 
would be best for adding goodies. 

Another thing that helped with 
debugging was making the "save 
game" format compatible between the 
d i f f eren t versi o n s of t h e en gi n e. Si n ce 



we automatically saved the 
game at regular intervals, if 
the play-testers crashed the 
game we would usually 
have something not too far 
from where they encoun- 
tered the bug. Si nee these 
files would even work if the 
code base they were testing 
was several versions old, it 
made normally rare and 
hard to duplicate bugs rela- 
tively easy to find and fix. 
Our save game format 
allowed us to add data, 
delete data, add and delete 
code (we even supported 
function pointers) at will, 
without breaking anything. 
Thisalso allowed usto 
make some fairly major 
ch an ges after we sh i pped 
the game without interfer- 
ing with any of our players' hard-won 
saved games. 



No Good Deed Goes Unpunished 

Until the Cabal process got under- 
way, technology was added to 
Half-Life freely. It was assumed that "if 
we build it, they will come," meaning 
that any new technology would just 
naturally find a creative use by the con- 
tent creation folks. A prime example of 
this fallacy was our "beam" effect, basi- 
cally a techniquefor doing highly tun- 
able squiggly glowing lines between two 
points; stuff like lightning, lasers, and 
mysterious glowing beams of ener- 
gy. It was added to the 
engine, the parameters 
were exposed, and an 
e-mail was sent out 
explaining it. The result 
was . . . n oth i n g. After two 
months only one level 
designer had put it in a 
map. Engineering was 
baffled. 

During the Cabal process, we real- 
ized that although the level designers 
knew of the feature, they really had no 
clear idea of what it was for. The para- 
meters were al I very cryptic, and the 
wrong combinations would cause the 
beams to have very ugly-looking 
effects. There were no decent textures 
to apply to them, and setting them up 
was a bit of a mystery. It became very 
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Second-Order Effects 




arly in the development of 
Half-Life, skeletal animation 
was added solely for compres- 
sion reasons; we needed to be 
able to store a lot more frames of anima- 
tion in fewer bytes than were required by 
vertex animation. The DSP effects and the 
reworldng of the sound system, were 
added solely for the ability to add echo 
and other single-processing effects. 
Adding a mouth to the various humanoid 
models was solely for the humor value of 
having the scientists scream while play- 
ing specific scripted sequences. Each by 
itself was considered complete. 

Then the animator who added the 
mouths asl<ed the programmer who wrote 
the DSP code if there was any way to 
mal<e the mouth move when the character 
tallied. He was told it would be easy to 
l<now when the character was tailing but 
that there wasn't any way to automatical- 
ly move the jaw. He then asl<ed the pro- 
grammer who wrote the sl<eletal anima- 
tion code if there was any way to mal<e 
the mouth move when the character 
tallied. He was told it would be easy to 
move the jaw, but that there wasn't really 
any way to tell when they were talldng. 
Independently, both programmers told 
him that it was impossible to do and to 
quit bugging them about it. It wasn't until 
several weel<s later when the program- 
mers were sitting around commenting on 
what new impossible feature the artists 
wanted that they realized that the part 
neither one of them understood was in 



fact trivial. About an hour later, the char- 
acters in the game could tall<. 

Of course, that wasn't the end of it. 
Since the Cabal had just started, and 
since we now had a solution to the prob- 
lem of how to explain to the player what 
was going on — now other characters 
could tell them — it was time to reworl< 
our existing designs. With the ability to 
tall< to the player, we now needed some 
character in the game that the player 
would actually want to tall< to instead of 
just Idlling right away. We decided that 
the trigger-happy security guard mon- 
ster — originally designed as an easy 
version of the soldiers — should instead 
be a supporting character. The scientists 
also went from being fairly ambiguous 

— good or evil, we had them both ways 

— to being definitely on the player's 
side. It also meant that instead of claim- 
ing we had a story because we included 
a bunch of prose in a README.TXT file 
somewhere, we could have a real author 
do real dialog with real (within technical 
limits) characters and use real story- 
telling techniques. 

We've come to the conclusion that 
major ideas can come from anyone, and 
that most technologies have hidden fea- 
tures in them that will be discovered only 
after the initial technology is in place. For 
this reason, it's critical to include every- 
one in the design process and create a 
mechanism to feed these second-order 
effects bacl< into the development 
process. 



clear thetechnology itself was only a 
small part of the work and integration, 
training, and follow-through were 
absolutely necessary to make the tech- 
nology useful to the game. Writing the 
code was typically less than half the 
problem. 



Square Pegs 



Practically speaking, not everyone 
is suited for the kind of group 
design activity we performed in the 
Cabal, at least not initially. Peoplewith 
strong personalities, peoplewith poor 
verbal skills, or people who just don't 
likecreating in a group setting should- 
n't be forced into it. We weighted our 



groups heavily toward peoplewith a 
lot of group design experience, well 
ahead of game design experience. Even 
so, in the end almost everyone was in a 
Cabal of one sort or another, and as we 
got more comfortable with this process 
and started getting really good results it 
was easier to integrate the more reluc- 
tant members. For current projects, 
such as Team Fortress 2, the Cabal 
groups are made up of 12 or more peo- 
ple, and rarely fewer than eight. The 
meetings ended up being shorter, and 
they also ended up spreading ideas 
around a lot quicker, but I'm not sure 
I 'd recommend that size of group 
initially. 

Just about everything in Half-Life 
was designed by a Cabal . This at first 



seemed to add a bit of overhead to 
everything, but it had the important 
characteristic of getting everyone 
involved in the creation process who 
were personally invested in thedesign. 
Once everyone becomes invested in 
thedesign as a whole, it stops being 
separate pieces owned by a single per- 
son and instead the entire game design 
becomes "ours." 

This "ours" idea extended to all lev- 
els. Almost every level in the game 
ended up being edited by at least three 
different level designers at some point 
in its development and some levels 
were touched by everyone. Though all 
the level designers were good at 
almost everything, each found they 
enjoyed some aspect of level design 
more than other aspects. One would 
do the geometry, one would do 
monster and A! placement, our tex- 
ture artist would step in and do a tex- 
turing pass, and then one would fin- 
ish up with a lighting pass, often 
switching roles when needed due to 
scheduling conflicts. This became crit- 
ical toward the end of the project 
when peoplefinished at different 
times. If a play-test session revealed 
something that needed to be changed, 
any available level designer could 
make the changes without the game 
getting bottlenecked by needing any 
specific individual. 

This idea also extended to all code, 
textures, models, animations, sounds, 
and so on. All were under source control 
and any individual was able to synch up 
to the sources and make whatever 
changes were necessary. With a little bit 
of self-control, this isn't as random as it 
sounds. It had the added benefit in that 
it was fairly easy to get a daily record of 
exactly what was changed and by 
whom. We would then feed this infor- 
mation back into the play-test cycles, 
only testing what had changed, as well 
as helping project scheduling by being 
able to monitor the changes and get a 
pretty good esti mate of th e stabi I i ty an d 
completeness of any one component. 
This also allowed us to systematically 
add features throughout the process 
with minimal impact. Oncethetechni- 
cal portion was completed, the engineer 
assigned to the feature was able to 
synch to all the source artwork and 
rebuild any and all files (models, tex- 
tures, levels, and so on) affected by the 
change. 
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The skeletal system allowed the team to change its monster 
appearance throughout the development process with mini- 
mal impact on existing animations andAI. 



By placing traditional combat action in more challenging 
environments we were able to intensify the feeling of ten- 
sion and suspense. 



Ine worKers lontroi me rieans or 
Production 

Even with all emphasis on group 
activity, most of the major features 
of Half-Life still only happened 
through individual initiative. Everyone 
had different ideas as to what exactly 
thegame should look like, or at least 
what features we just had to do. The 
Cabal process gave these ideas a place 
to be heard, and since it was accepted 
that design ideas can come from any- 
one, it gave people as much authority 
as they wanted to take. If the idea 
required someone other than the 
inventor to actually do the work, or if 
the idea had impact on other areas of 



the game, they would need to start a 
Cabal and try to convince the other 
key people involved that their idea was 
worth the effort. At the start of the pro- 
ject, this was pretty easy as most every- 
one wildly underestimated the total 
amount of work that needed to be 
done, but toward the middle and end 
of the project the more disruptive deci- 
sions tended to get harder and harder 
to push through. It also helped filter 
out all design changes except for the 
ones with the most player impact for 
the least development work. 

Through constant cycle of play-test- 
ing, feedback, review, and editing, the 
Cabal process was also key in remov- 
ing portions of the game that didn't 



Technology Integration Tips 



Work directly with the artists — 
level designers, animators, and so on — 
for however long it tal<es to get the tech- 
nology into a sample portion of the 
game. Sit in their office. Hang out. 
Watch what they do. Watch what they 
try. At this point, you will probably need 
to simplify, enhance, and/or document 
the interface better. 

Have the artist demo the technology 
to the rest of their group. When it comes 
from outside, it'll be viewed with a certain 
amount of sl<epticism. When it comes 
from within, it'll be viewed as a new tool. 

Reintegrate the technology into the 
world. You've spent the time adding the 



new technology, but if the player never 
sees it, then all your work will be wasted. 
Mal<e sure it gets into the game design 
document. Maybe it should be used 
instead of other effects. Maybe it can be 
used to enhance an existing portion. 
Mal<e sure it gets into as much of the 
game as possible. 

Keep track of how the technology is 
used. After a few months you will proba- 
bly notice that the technology is being 
used to do things you never considered. 
Analyze how it's being used and look for 
improvements or new tools that can mal<e 
it even better. You'll need to l<eep this up 
for the entire project. 



meet the quality standards we wanted, 
regardless of the level of emotional 
attachment the specific creator may 
h ave h ad to th e work. Th i s was on e of 
the more initially contentious aspects 
of the Cabal process, but perhaps one 
of the more important. By its very 
nature, the Cabal process avoided 
most of the personal conflicts inher- 
ent in other more hierarchical organi- 
zations. Since problems were identi- 
fied in a relatively objective manner 
of play-testing, and si nee their solu- 
tions were arrived at by consensus or 
at least by an individual peer, then an 
authority that everyone could rebel 
against just didn't exist. 

On a day-to-day basis, the level of 
detail supplied in even a 200-page 
design document is vague at best. It 
doesn't answer the 1,001 specific 
details that each area requires, or the 
countless creative details that are part 
of everyday development. Any design 
document is really nothing more than 
a framework to work from and some- 
thing to improve the likelihood that 
work from multiple people will fit 
together in a seam I ess fash ion. It's the 
Cabal process that helped spread 
around all the big picture ideas that 
didn't make it into any document — 
things that are critical to the feel of 
thegame, but too nebulous to put 
into words. It also helps maximize 
individual strengths and minimize 
individual weaknesses and sets up a 
framework that allows individuals to 
influence as much of the game as pos- 
sible. In Half-Life, it was the rare area 
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HALF-LIFE LESSONS 



Placing the player in a soldier-vs.- 
alien conflict tielped reinforce tlie 
illusion of an active environment, and 
let Valve stiow off its combat A! witti 
minimal risl< to ttie player. 



of the game that did- 
n't include the direct 
work of more than ten 
different people, usu- 
ally all within the 
same frame. 

In order for highly 
hierarchical organiza- 
tions to be effective, 
they require one per- 
son who understands 
everyone else's work 
at least as well as the 
individuals doing the 
work, and other peo- 
ple who are willing to 
be subordinates yet 
are still good enough 
to actually implement 
the design. Given the complexity of 
most top game titles, this just isn't 
practical — if you were good enough 
to do thejob, why would you want to 
be a flunky? On the other hand, com- 
pletely unstructured organizations 
suffer from lack of information and 
control — if everyone just does their 
own thing, theoddsthat it'll all fit 
together in the end are somewhere 
around zero. 




Ttie first incarnation of ttie game's main character, now 
l<nown affectionately as "Ivan the Space Bil<er." 



At Valve, we're very happy with the 
results of our Cabal process. Of course, 
we still suffer from being overly ambi- 
tious and having, at times, wildly 
unrealistic expectations, but these 
eventually get straightened out and 
the Cabal process is very good about 
coming up with the optimal compro- 
mise. Given how badly we failed ini- 
tially, and how much thefinal game 
exceeded our individual expectations. 



even our most initially reluctant per- 
son is now a staunch supporter of the 
process. ■ 



Back 
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s maintaining your game libraries becoming more and more 



of a cli all en ge? I s you r gam e's cod e base beco m i n g i n creasi n gl y 
fragile? This isn't an uncommon phenomenon. We've all 



heard about projects that were cancelled dueto unmaintain- 



able code and runaway bug counts. Perhaps you've even 



been part of such a project. The key to avoiding this kind of 
catastrophe lies in good code design and a willingness to set 



a certain level of discipline in your 
team's coding style. 

Game development offers a unique 
challenge to programmers because of 
its combination of cutting-edge tech- 
nology and traditional software devel- 
opment challenges. Often, traditional 
solutions to program design tend to 
fall short because of the rapid evolu- 
tion of game development technolo- 
gies. For instance, M icrosoft's DirectX 
libraries constantly evolve, and each 
new version has new features and 
takes advantage of new hardware and 
technologies. But trying to ensure that 
your programs will be able to use the 
newest versions of DirectX without 
having to rewrite lots of code is made 



more difficult in the process. The 
ability to design upgradability into 
your software libraries without sacri- 
ficing stability is a rare art today, but 
it doesn't have to be so. To combat 
f ragi I e code, th i s arti cl e exam i n es 
some traditional approaches and dis- 
cusses the benefits and limitations of 
these methods. 



Ever-Increasing Complexity 

The day of the free-coding, seat-of- 
your-pants, l-don't-believe-in- 
desi gn i n g-code-before-l -wri te-i t pro- 
grammer isfast drawing to an end. 
Today's top games have become as 



sophisticated as mainstream commer- 
cial applications, and many compa- 
nies feel the pressures that inspired 
more efficient design methodologies 
such as object-oriented programming 
and the concepts of design patterns. 
As programs get larger and more 
complex, the number of interdepen- 
dences between code modules tends 
to increase at an exponential rate, 
making code reuse or redesign more 
difficult. Companies that do not 
feel compelled to design their 
software effectively will eventually 
be surpassed in the marketplace by 
those who do, producing more bug- 
free code with a shorter turnaround 
time. 



James Boer is thedesigner and oneof the programmers who brought you Deer Hunter and Deer Hunter II (and hestill has never 
gonehunting). Other game credits include Rocky Mountain Trophy Hunter, Pro BassFishing, Microsoft Baseball 2000, and 
Microsoft Internet Hearts. Hecurrently is working at W izBang! Software in Seattle, W ash., on a yet unannounced product, and 
can be reached for comments, questions, or general adviceabout virtual deer hunting at jbsys@compuservacom. 



GAME DEVELOPER DECEMBER 1999 



http://w WW .gdmag.com 



FIGURE 1 . Cohesion between code and data. 




The Pitfalls of Procedural 
Programming 

In procedural programming, data is a 
distinctly separate entity from the 
code that operates on that data (Figure 
1). This creates a situation in which 



numerous modules of code might be 
looking at a single chunk of data. As 
the number of code and data modules 
increases, you tend to see data and 
code modules become more dependent 
on each other. This web of dependen- 
cies, often called "code cohesion," 
makes it increas- 
ingly difficult 
to alter any one 
component with- 
out adversely 
affecting the 
others. 

When game 
code becomes too 
cohesive, the 
entire system 
must either be 
redesigned or dis- 
carded due to its 
inherent lack of 
flexibility. This 
process is known 
as refactoring, 
and it is an 
inevitable part of 
any software 
development 
cycle. The prob- 
lem is not how to 
avoid the need to 



ref actor your software. This is an unre- 
alistic goal, as no developer can antici- 
pate changing future requirements to 
the degree that it will never need to be 
redesigned at a fundamental level. 
However, you can strive to maximize 
the effective lifespan of code. This goal, 
achieved through the use of reusable 
components which encapsulate both 
code and data, was what object-orient- 
ed programming (OOP) promised to 
deliver. Unfortunately, OOP can't pro- 
vide all the answers on its own. (See 
sidebar, "Code Cohesion," p. 58) 

Shortcomings of OOP 

OOP encapsulates code and data 
into a single module, which in 
essence, gives the data a code i nterface. 
This means that the underlying data 
can be changed without modifying the 
interface to access that data, which 
provides an additional level of protec- 
tion when requirements change. How- 
ever, just as dependencies between 
code and data modules can escalate to 
an unmanageable level, dependencies 
among different code modules can also 
create an unmanageable level of cohe- 
sion (Figure 2). 

Using OOP techniques has simply 
delayed the progression of the cohe- 
sion by combining code and data mod- 
ules. As programs grow in complexity, 
however, the code dependencies still 
i n crease to an u n desi rabi e I evel . To 
move away from the abstract a bit, let's 
take a look at a real problem and see 
how a real solution was implemented. 



Real-Life Problem: A DirectX Upgrade 

Theissueof using DirectX libraries 
effectively is something most PC 
game developers have had to face. 
Although these libraries attempt to 
remain backward-compatible with the 
interfaces of previous versions, there are 
times when compatibility must be bro- 
ken in order to introduce new features. 
It is at this point that your existing code 
becomes incompatible with the new 
libraries. The typical OOP solution to an 
evolving interface is the creation of a 
thin wrapper class for the library, which 
usesinlinefunctionsto shield thegame 
programmer from the more mundane 
tasks involved in using the library. 



FIGURE Z. In OOP, different code modules can become too 
dependent upon eacli otiier. 
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Code Cohesion 

hat is code cohesion, 
what causes it, and 
exactly why is it such 
a bad thing? Cohesion 
is the result of too many parts of a pro- 
gram becoming dependent on each other. 
Of course, some cohesion happens by 
necessity in any program written, but the 
degree of cohesion is what's important. If 
the amount of cohesion remains low, it is 
easier to replace any particular subsys- 
tem of code because the impact on other 
portions of the code will be minimal. If, 
on the other hand, the code is highly 
dependent upon specific interfaces and 
data structures from many other parts of 
the program, it becomes impossible to 
change without affecting a vast number 
of other systems. 

Cohesion is caused by a number of 
things, but there are some more obvious 
coding practices to watch out for. Here 
are some programming practices which, 
unless used cautiously, can lead to highly 
cohesive code: 

1. Using global variables and data 
STRUCTURES. There are some instances 
where globals might be necessary, but 
thinl< long and hard before using them. 
More often than not, these types of items 
can be encapsulated in a class with little 
ill effect. Structs, unless used exclusively 
inside a particular class, should be used 
with caution. Wrapping data and func- 
tionality into a single class is usually a 
safer approach. The biggest problem with 
using a struct to store common data is 
that it's difficult to manage and tracl< who 
is actually accessing the data and when 
they are doing it. 

2. Incorrect scaling of classes at 
DESIGN TIME. It's a common mistal<e for 
programmers to design their classes too 
small and specific, resulting in many 
smaller interdependent objects, or too 
large, resulting in complex, monolithic 
objects that attempt to do far too much. 
It's important to design and use classes 
at both ends of the size scale, both to 
l<eep code modules small and readable, 
yet also to l<eep the overall design rela- 
tively understandable. 



3. Allowing many small objects in dif- 
ferent SUBSECTIONS OF THE CODE TO COMMU- 
NICATE DIRECTLY WITH EACH OTHER. Although 

this is sometimes unavoidable, you 
should always try to mal<e use of a high- 
level interface to communicate between 
subsections of code. Inline function can 
alleviate most concerns about addition 
overhead imposed by the additional 
interface layer. If direct communication 
between smaller objects absolutely must 
occur, try to utilize some communication 
abstraction if possible as a go-between, 
such as a message object. 

Alternatively, here's three techniques 
you can use to ensure you're code doesn't 
become too highly cohesive. 

1. Make good use of libraries. If you 
can separate your code from the applica- 
tion and place it into a library, you've 
established a natural separation that can- 
not easily be breached. Objects in the 
library have to remain relatively indepen- 
dent of the code in the application. 

2. Focus ON THE "BLACK BOX" INTERFACE OF 

YOUR OBJECTS. Your objects should be per- 
forming tasl<s under the hood, without 
other programmers having to worry about 
exactly how the tasl<s are being imple- 
mented. This means that you should l<eep 
the public function available for use, mal<e 
sure that it's easily implemented, and doc- 
ument it well (including good comments 
within the code). Keep your helper func- 
tions private or protected. If you find the 
number of functions growing extremely 
large, perhaps it's time for a higher-level 
object to tal<e over the tasl<, or to consoli- 
date a number of the smaller functions 
into larger, simpler-to-use function. 

3. Have a solid design strategy before 
CODING STARTS. This sounds a bit too sim- 
plistic to be a practical rule, but it's an 
important one nonetheless. Don't resign 
yourself to the illusion that you'll go bacl< 
later and "do it right." In my experience, 
there's rarely the time or inclination to do 
that. Once code is written and "worldng," 
it's hard to convince someone that you 
need to go bacl< and spend more time to 
rewrite code that essentially does exactly 
the same thing. 




For example, blitting from surface to 
surfacein DirectDraw requires the pro- 
grammer to fill out a number of para- 
meters in theIDirectDrawSurface4::Blt() 
method, including source and destina- 



tion rectangles, a source surface, flags, 
and a blit structure. The Component 
Object Model (COM) structure, on 
which DirectX is based, provides much 
in the way of standardization, but 



unfortunately it has no concept of 
default parameters and function over- 
loading. So you might consider writing 
wrapper Bit functions which are easi- 
er to use. You also might have several 
overloaded BltO functions for different 
situations. Class wrapping likethis 
makes an API easier to work with and 
also helps shield the application from 
ch an ges i n (for th i s case) th e 
DirectDraw interface. If function para- 
meters within BltO change, a program- 
mer must only make changes inside 
the wrapper functions instead of 
throughout the game. 

Unfortunately, this doesn't provide 
protection from major changes in an 
API's functionality. For instance, in 
DirectX 6.0, Microsoft introduced 
Direct3D vertex buffers as an alterna- 
ti ve to execute buffers. Th i s type of 
change typically has more far-reaching 
effects in an application than a simple 
change in a function's parameters. So 
some solution must be found to pro- 
tect code subsystems from major 
changes in one or more basic compo- 
nents of another system. 



The Facade Pattern: Half a Solution 

The facade pattern provides a solu- 
tion to the seemingly inevitable 
cohesion between different modules of 
code in a program. The basic premise 
of the facade pattern is this: all code 
must be logically divided into discreet 
modules, and these modules should, 
whenever possible, communicate to 
each other through the use of an inter- 
face known as a facade. The facade is a 
high-level interface to thefunctionality 
of a complete subsystem of objects 
which work together to perform some 
related task. There will be times when 
lower-level functionality of a system 
must be accessed directly, but often the 
facade can take care of higher-level 
functions more easily than another 
solution. 

These are not radical or even new 
concepts. Most programmers have 
seen the benefits of some sort of man- 
ager class that is used as the interface 
to th e rest of th e program . U si n g a 
system such as this helps to insulate 
the remainder of a program when the 
implementation of a subsystem 
radically changes under the hood 
(Figures). 
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FIGURE 3 . Visual representation of communication between subsystems using 
facades. 




The Virtual Manager Alternative 

Although thefacade works well, it 
does present some serious limita- 
tions. Let'sassume we wish to build a 
facade over every one of our major 
subsystems, which we've split into 
separate libraries. This means that 
each major library has a facade to 
handle communication to and man- 
agement of the subsystem, creating a 
cleaner interface between each subsys- 
tem and with the application. How- 
ever, most applications require some 
customization of their libraries to one 
degree or another as the requirements 
of the application evolve over time 
and new features are added. If more 
than one application uses the same set 
of libraries, then thecustomizations 
must occur at the application level, 
instead of the library level. The prob- 
lem then boils down to: How can we 
customize the libraries at the applica- 
tion level and still allow other 
libraries to use those custom izati on s? 

A while back, we discovered a prob- 
lem when working on specific library 
modules that needed to access code in 
other libraries we had written. TheUI 
library, for example, required theuseof 
our Graphics and Input libraries. How 
can we en su re th at th e U I I i brary can 
access those other libraries' functionali- 
ty, even though an application may 
wish to extend theGraphicsor Input 
libraries by deriving new classes from 
them at the application level? 

The answer lies in the clever use of a 
static pointer. By instantiating a class 
at the application level and passing 
the pointer of that object back to the 



class to store as a static member, we 
give every piece of code, whether at 
the library or application level, the 
ability to access the object that the 
application has created. This object 
may bean instanceof the class which 
resides in the library, or it may actual- 
ly bean instanceof a class derived 
from it. From the other library mod- 
ule's point of view, it makes no differ- 
ence. The solution is simple and ele- 
gant, and provides a good deal of 



flexibility. Here's what the code looks 
like: 

// sample code showing a generic manager 
// class 

class ManagerBase 
{ 

public : 

ManagerBaseO; 
virtual ~ManagerBase() ; 

ManagerBase* GetBaseO 
{ return m.pBaseObj; } 

void SetBase(ManagerBase* pObj) 
{ m.pBaseObj = pObj; } 

protected: 

static ManagerBase* m.pBaseObj; 

}; 

We see a simple mechanism for stor- 
ing a single object in its own static 
member. Access to the object is 
achieved through theGetBaseO func- 
tion. However, in order to avoid hav- 
ing to type in: 

ManagerBase: :GetBase()->DoSomeFunction() ; 
every time we want to call a function, 
we can simplify the call through the 
strategic use of an inlinefunction. 
inline ManagerBase* ManagerO 
{ return ManagerBase: :GetBase(); } 



Design Patterns 

There's been a lot of talk about 
design patterns in the world 
of object-oriented program- 
ming (OOP). In a nutshell, a 
design pattern is a simply way of 
describing the general object-oriented 
form of a solution to a specific type of 
programming problem. If this sounds a 
little vague or abstract to you, it should. 
Patterns only give you a blueprint of 
object interaction to model your own 
classes on. After that, it's up to you to 
build the specific classes that solve 
whatever problem you're facing. What 
the pattern gives you is a strategy when 
deciding which objects to use, and how 
they should worl< together. 

Effective object-oriented design is one 
of the more elusive sidlls a programmer 
can master. C++ is really not all that 
hard to learn at the basic language level. 
After all, one doesn't necessarily have to 
use templates, exceptions, and other 
fancy language features. However, it has 



a reputation of being a difficult language 
to master due in part to the complex art 
of designing classes that are clean, effi- 
cient, and expandable. Patterns can help 
shorten this learning curve by describing 
common programming problems, then 
showing how a class or hierarchy of 
classes can be used to solve the problem 
with proven, time-honored class 
designs. 

In addition to allowing programmers to 
see practical object-oriented solutions to 
programming tasl<s that they may 
encounter, patterns also give program- 
mers a common frame of reference when 
tailing about programming solutions by 
naming the patterns. If I describe a class 
utilizing a Factory pattern (a Factory is 
responsible for creating objects and 
returning interfaces to them), anyone 
who understands what a Factory pattern 
is automatically can relate to the general 
nature and purpose of the class that I'm 
attempting to describe. 



Thisfunction is placed just below the 
class definition in the header file, and 
should be used to access the object. 
Code calling the manager then looks 
I i ke th i s: 

Manager ()->DoSomeFunction() ; 
This looksquitea bit more friendly, 
and because the function is inline, 
requires no additional overhead. 

You'll notice that the class was named 
ManagerBase instead of Manager. Thiswas 
done with the foresight of knowing that 
the inlineaccessor function, not the 
object, should havethe name most 
closely associated with the actual func- 
tionality of the object. For instance, 
with a sound manager, you should 
name the object SoundManagerBase, which 
I eaves you free to name the accessor 
function SoundManagerO. 

The application isresponsiblefor cre- 
ating the manager object and passing 
back to th e cl ass for storage, I i ke th i s: 
// application initialization code 

ManagerBase* pBase = new ManagerBase; 
ifdpBase) 

return Error; 
ManagerBase: :SetBase(pBase) 

// now we're ready to call the manager 
// functions 

Manager ()->DoSomeFunction() ; 



Because theapplication isresponsible 
for creating and setting the object, it's 
possi ble to try to access the manager 
without having initialized it. Thiswill 
result in an access violation, so it is 
important to guard against this. Ideal- 
ly, the object should be created at the 
beginning of theapplication and 
destroyed attheend, which will guard 
against this type of error. If for any rea- 
son parts of your code might try to 
access a manager before it has been cre- 
ated , i t i s y u r respo n si b i I i ty t o w rap 
that code in an if statement which 
checks to see that a valid object exists 
before accessing it. This is the biggest 
drawback to this system, but with care- 
ful planning it doesn't have to be a 
problem. 



A Keal-Lite Solution 

For an example of a practical solu- 
tion, let's look at a sound manager, 
as i t's a rel at i vel y si m p I e su bsystem . 
Most sound managers consist of code 
that manages a list of sounds, and can 
load, unload, play, stop, or set proper- 
ties of any of these sounds on demand. 
Most applications should beableto use 
this set of functions without much 
alteration. 



At theapplication level, however, 
the ben efi ts of o verr i dingtheman ager 
class become quickly apparent. For 
instance, you may wish to add the 
capabilities of associating some other 
types of data with some sounds. For a 
technology demo of an upcoming 
product we were showing to publish- 
ers, we associated a lip-synch data file 
with voice-over recordings. After the 
voice-over sounds were loaded, we 
could retrieve the associated data file as 
well. 

A class, which we'll call 
AppSoundManagerObj, is derived from 
SoundManagerBase. In addition to deriving 
the class from the base class, we'll also 
create a new accessor function, like 
this: 

inline AppSoundManagerObj * AppSoundManagerO 
{ return ((AppSoundManagerObj 
*)SoundManager()); } 

This new accessor gives us a pointer 
to the new AppSoundManagerObj interface, 
which of course also includes the inter- 
face to th e ori gi n al base man ager cl ass. 

In addition to adding new members 
to th e deri ved cl ass, th e abi I i ty to 
derive means that we also gain the abil- 
ity to change default behavior of the 
manager classes by overriding virtual 
functions. This effectively lets us 
change the behavior of the manager 
even when it is called from other 
libraries. 



Migrating Library Code 

An advantage of the virtual manag- 
er system is that most new code 
can first be introduced at theapplica- 
tion level without modifying the exist- 
ing libraries. If you want to use those 
features later in other applications 
sharing the same libraries, then it's 
simpleto mi grate the code from the 
application level to the library level 
(Figure4). It's important to note that 
when NewFuncO, as shown in the dia- 
gram, moved from App 1 to the 
Library, no changes to the interface 
were apparent to the rest of the pro- 
gram . Th e beauty of th i s system i s th at 
migrating code in a virtual manager 
class doesn't affect the interface as seen 
by the rest of the program. 

In addition to the ease with which 
you can migrate code from application 
to library, the virtual manager also cre- 
ates, to a limited extent, a primitive 
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version ing scheme. You can see how, 
by creating several layers of derived 
classes, you could easily choose at the 
application level which version of a 
library you wished to use. 

While there certainly is no nnagic for- 
mula to eliminate bugs from a software 
product, a well-planned and solidly- 
developed library can certainly go a 
long way in stabilizing your code. By 
ut i I i zi n g wel I -estabi i sh ed obj ect-ori en t- 
ed programming principles and solid 
code management techniques, you'll 
find that perhaps you'll be able to 
focus more energy and spend more 
ti me wri ti n g n ew code i n stead of track- 
ing down bugs and rewriting old 
libraries. ■ 



FIGURE 4 . Migration of code from application-level facade to library-level 
facade. . 
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fter a long series of successful titles such as Mech Warrior 
2: Ghost Bear's Legacy and M ech Warrior 2: M ercen- 
ARiES, Activision held a dominant position in the 
giant-robot genre. Due to the commercial success 
of this series, though, a tidal wave of similar 
products developed by worthy competitors 
began to flood the market. Fortunately, Activision found a new and 
exciting universe in Dream Pod 9's Heavy Gear pen-and-paper-based 
game, and in thefall of 1997, Activision Studios began production on 
the futuristic giant-robot simulator Heavy Gear II. Heavy Gear II allows 
game players to suit up in a giant, high-octane, h u man esq ue battle tank 
called a "Gear." The player is then required to outfit a wily band of Al 
Gears (called "squadmates") and arm them to theteeth. Their small but 



Beyond the role of volcanic guitarist and avid jai alai analyst, Clancy enjoys all aspects of engine 
design including 3D graphics, Al, tools, and multi player integration. For Heavy Gear II, he 
was responsible for the Al, scripting system, and tools development. Contact him at 
cimislund@activision.com. 
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heavily armed reconnaissance force must infiltrate and over- 
come a rich variety of environments including swamps, icy 
wastes, angry red planets, and the weightless reaches of 
outer space. The action in Heavy Gear II is much faster than 
in other giant robot simulators, as Gears are substantially 
smaller than Mechsandmuch more fragile. This requires 
squads to rely primarily on stealth and cunning rather than 
brute force and wanton destruction. Players are forced to 
pick their battles wisely or face annihilation from the superi- 
or enemy legions that infest the various worlds they tra- 
verse. When pi lots are tired of playing against computer 
opponents, they can pit themselves against human enemies 
in multiplayer mode with a number of game types to choose 
from including "steal the beacon," "king of the hill," and 
good old-fashioned death match. 

To create such an experience, Acti vision assembled a new 
team of its best and brightest in the areas of programming, 
art, design, and management. A very aggressive schedule was 
adopted targeting a fall 1998 release date (a 13-month devel- 
opment schedule). Our original staff consisted of a lead, 
graphics. A! and tools, multiplayer and shell programmer. 
We had a lead artist, two 3D modelers, a 3D animator, and 
two 2D artists creating texture maps for the models and ter- 
rain. We also had a lead designer who managed a group of 
three game designers, all of whom transformed the storyline 
from paper into a computer game. Our management group 
consisted of a director, a producer, and an associate produc- 
er, who controlled the schedule and the development and 
direction of the game and saw to the many needs of the 
other production staff. 

We programmers were chartered to create a new game 
engine and I took on the role of A! , scripting system, and 
tools programmer. At the heart of this engine was a rock- 
solid memory management and leak-tracking class. Yes, 
that's right. Before anyone ever dreamed of fancy graphics or 
stunning game play, we had to deal with this mundane task. 
Every C -H- cl ass an d stru ctu re used by th e D arksi de en gi n e 
h ad roots wi th i n th i s base cl ass. Th i s arch i tectu re al I owed to 
us to detect memory leaks and overwrites as soon as they 
appeared in a given day's build, which allowed usto address 
problems immediately rather than during a grueling cycle at 
the end of the project. I cannot stress the importance of this 
typeof planning and execution enough for teams who want 
to craft a state-of-the-art game engine. Focusing on the relia- 
bility of the application will also greatly increase the immer- 
sion factor of any game that's created with it. After all, what 
destroys immersion more than a hard system crash? Hats off 
to our lead who took us down this path. 

The decision was made to target the game only for 
machines outfitted with 3D -accelerated video cards. This 
issue was hotly disputed within our team for a while, but 
when our management group realized that in order to pull 
off realistic 3D graphics, software emulation was a dead deal. 
This had profound effects on the schedule, as it freed our 
artists and programmers from dealing with thetime- 
consuming and tiresome work of generating alternate LODs 
for such a purpose. This decision also eliminated a huge 
chunk of our QA test plan, which could have pushed back 
the release date of the title significantly further. We had to 
choose between putting out the highest quality game we 
could and targeting a consumer market that barely existed at 




that point, or publishing a game that had a greater current 
market base and little or no novelty by the time it was 
released. I suppose it is something all of us developers must 
deal with in these days of rampant technological change. 

The Al system was another great challenge, as it would 
dictate much of the feel of the game. It would also be a key 
tool for our design team as they implemented the complex 
storyline. We decided at the high level to go with a pure 
"autopilot" approach, in which enemy and friendly Al alike 
were able to function intelligently without any script at all 
for individual units. Wewanted to beableto put a unit into 
the world and have it go do whatever it thought it needed to 
do. Internal to this was a high-level strategic system, ateam- 
based tactical system that employed a knowledge base, and a 
low-level, unit-specific order execution system. The goal was 
to take much of the burden off of the design staff, and give 
thegamea consistent and distinctive feel across all missions. 

Nonetheless, our scripting system was very effective and 
had some nice features such as an in-game debugger com- 
plete with break points, single-step execution, and variable 
watch windows. It was based on L EX X/YACC -based C gram- 
mar, which hooked into a powerful and easily extensible vir- 
tual machine that resided in the D arksi de engine. Our script- 
ing system was hooked in to our custom game API, which in 
turn was coupled to prototypes defined in a file called 
SrDHG2.H, which ostensibly replaces STD 10. H (afilewell 
known to all of you C programmers out there). Amazingly 
enough, SrDHG2.H was used not only to compilethe 



1^ 



EAVY Gear II 




Activision 

Santa Monica, Calif. 

(310) 255-2000 

httn- / /www. activision. com 
Release date: July 1999 
Intended platform: Windows 95/98 
Project length: 19 months 
Team size: 20 

Critical development hardware: 3D-accelerated 200IVIHZ PC 
Critical development software: Softimage 3.7, Photoshop, 

Visual C++ 5.0, Visual SourceSafe, and numerous in-house 

tools 



http://w w w .gdmag.com 



DECEMBER1999 GAME DEVELOPER 



POSTMORTEM 




scripts, it was also used in thecompila- 
tion of the Darkside engine itself. This 
convenient relationship between the 
scripting language and the engine 
source code, pi us the fact that the C 
language is widely documented, easily 
justified our decision usea scripting 
language based on C. Scripts were used 
mainly to monitor mission progress 
and objectives, special behaviors (con- 
voys and patrols, for instance), and 
interactive control of theaction. Our 
goal was to keep these scripts as simple 



LISTING 1. Event callback requests. 



II A Script. C 
void 

Initialized 
{ 

// Tell AutoPilot that we want control 
// back when the unit is killed or 
// shot at 

AutoBreak(HitPointsExhausted) ; 
AutoBreak(ShotAt); 

// Turn over control to the autopilot 
// when this function returns 
AutoPilotO; 



} 



void 

ShotAtO 
{ 

RegisterString("Ha ha, ya missed"); 
// Resume auto mode 
AutoPilotO; 

} 

void 

HitPointsExhaustedO 
{ 

RegisterStringC'Damn! I died!"); 

} 



as possible. Theautopilot handled all 
strategic, tactical, and low-level opera- 
tions of unit behavior, yielding control 
only at the request of a script. The 
autopilot was the default A! handler in 
the engine. Scripts could override this 
system by posting event callback 
requests as shown in Listing 1. 

Our multi player system was crafted 
using a proven proprietary networking 
SD K devel oped at Acti vi si on . Th i s 
relianceon preexisting technology 
allowed us to get multiplayer function- 
ality in the engine and working very 
early on in the development cycle. 
Designing and integrating multiplayer 
functionality is often left until the end 
of a project, and that can create all 
manner of problems. Getting this level 
of complexity into our development 
schedule early probably saved the 
Heavy Gear II team an additional six 
months of work. 



What Went Right 



1 Effective prototypes. When I 
# began working with Activision's 
Heavy Gear II production team, it was 
composed of a lead programmer, a top- 
of-the-line3D graphics programmer, a 
director, a producer, a lead designer, 
and a lead artist. At that point, the 
team had just been given marching 
orders to produce a second prototype 
of the game for approval by the corpo- 
rate brass. I was hi red because this pro- 
totype required functional Al to give a 
feel of the intended game play. At this 
early stage, the game already looked 
super and a user-friendly 3D layout 
tool for the level designers was up and 
running. I couldn't believe the amount 



of work that these people put into pro- 
ducing the first prototype. Even more 
amazing was the fact that most, if not 
al I , of t h i s wo rk was of t h e " keeper" 
variety — nearly all the code used in 
the green-light prototypes exists in the 
Darkside engine today. Our design 
tools were augmented in functionality, 
but the basic underlying technology 
driving these applications remained 
virtually unchanged through the 
entire development cycle. 

2 The Darkside engine. The 
# Darkside engine created specifi- 
cally for Heavy Gear II was an engi- 
neering gem. Although game players 
get a solid dose of its extraordinary 
graphics and animation capabilities, at 
its core it is nothing but a simple mem- 
ory manager and leak tracker. This 
property of th e en gi n e al I owed th e pro- 
grammersto track down and remedy 
most of the nastier bugs in the game 
long before it hit the QA floor. Beyond 
i ts CO n Crete f ou n dati on , i ts mod u I ar 
design and expert use of C-H-made it a 
snap to add or delete the different sys- 
tems we wished to experiment with. 
Most of the foundation code and 
graphics subsystem was shared with 
our 3D layout tool, saving us a ton of 
extra work. This extensibility and prop- 
er use of the C-H- language was invalu- 
able as we faced a del uge of ch an gi n g 
design requirements and additional 
game features. Our 3D math library 
was easily modified for Intel's Katmai 
Instruction Set, and this enabled our 
OEM group to strike up some valuable 
partnerships with external vendors. 
Although some Heavy Gear 1 1 -specific 
code may still lurk in the recesses of 
the Darkside, the engine's debug ability 
and modularity make it a novel choice 
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for any 3D simulator Acti vision may 
wish to develop in the future. 

5 They let us do our jobs. Those of 
# you who have had the experi- 
ence of a tough supervisor or manage- 
ment group breathing down your neck 
as you tiptoed down your critical path 
will appreciate this: our front-line gov- 
erning body of director and producer 
did a superb job of trusting the profes- 
sionals who worked under them. They 
made our team aware of upcoming 
mi lestones and the expectations of 
Acti vision's corporate group without 
succumbing to the temptations of 
micro- management and general mega- 
lomania. This held true even when the 
team hit roadblocks or missed mile- 
stones. They maintained their trust in 
us. This contributed to a fertile envi- 
ronment for new ideas and creative 
solutions from the team. 

Activision's upper-level management 
also contributed to the game's success 
by letting the team decide when the 
game was finished. Management could 
have released the game early and 
announced a patch shortly thereafter, a 
practi ce th at i s becom i n g common 
with many publishers nowadays. 
Instead, Acti vision gave game players a 
break and released a quality, bug-scarce 
title with a lot of replayability and 
immersion. This is an admirable goal 
in this era of market-driven develop- 
ment and patch-laden gaming web 
sites. 

4 Great QA 
# WORK. 

With Activision's 
business plan, its 
development 
teams enjoy the 
luxury of a high- 
ly organized QA 
department. On 
the front lines we 
havea smaller group 
known as "produc- 
tion testers." These 
folks deal directly 
with the develop- 
ment team on a 
daily basis and 
intercept a 
high percentage 
of the bugs before 
they ever make it out to external test 
groups and Activision's QA team prop- 
er. Production testers become very inti 
mate with theinner workings of the 




game and are actually solicited 
for new ideas to improve the 
design. When the develop- 
ment team and production test 
team feel that the title has 
reached beta, Activision's main 
QA test group takes over for a 
formalized certification 
process. Concise reports are 
painstakingly generated to 
ensure that only genuine, 
replicable bugs ever make it 
back to the development 
teams. It is this group that is 
ultimately responsible for the 
rel ease of th e ti tl e, so th ey take 
their work very seriously. 

Beyond Activision's in-house 
QA department, we were aided 
by an eager external group 
called "Visioneers" who avidly 
played any build we furnished 
for them. They reported all 
manner of problems, from 
hardware compatibility issues 
to boring game play. The size and diver- 
sity of this group made them an ideal 
QA avenue, as they represented a more 
accurate cross-section of the gaming 
community. Activision also invited 
people from different age groups to 
come into our office and play Heavy 
Gear II in an observational setting. 
Testers' responses were noted and given 
to the development team via written 
surveys. All these channels of software 
evaluation greatly streamlined 
the development process 
and contributed 
heavily to the 
quality of thefin- 
ished product. 
Good game pacing. If 
you sit down and 
play Heavy Gear II, 
you will notice a com- 
pletely different feel 
from other games in the 
gen re. Th e pace i s faster 
and the action is much 
more compelling. This 
was a desi red feature 
documented in the 
original specification 
of the game, but writ- 
ing down that require- 
ment in a document 
doesn't necessarily 
mean you will pull it 
^Bfj^ off. At about the same 
time that Heavy Gear II 




Early sketches of CEF Heavy Battle Frame. 



was kicking off its production cycle, a 
series of first- person action shooters hit 
th e streets. M ost i f n ot al I of th e team 
members were avid deathmatch play- 
ers, and fierce competitions were held 
to decide which of us wasthetop dog. 
Subconsciously, much of the game- 
play feel we experienced wh ile partak- 
ing of th ese f rag-f ests f ou n d i ts way 
into our title. A fun enemy Al unit was 
one that somehow evoked the same 
emotional responseasthepoor slob I 
had just fragged at lunchtime. 

Thisheld truefor the Heavy Gear II 
multi player experience as well. We 
tried to translate what we thought was 
fun and exciting in our lunchtime 
death matches into experience of fight- 
ing against hulking Gears. I'm not say- 
ing that if you want to create a great 
title with lots of excitement that you 
should play first-person shooters, but I 
do think that it is important for all 
game developers to be avid players as 
well. It is the game player that has the 
upper hand at identifying the abstract 
notion of "fun" and, isn't it thejob of 
the developer to create that? 



What Went Wrong 

1. 



To DEMO OR NOT TO DEMO. I I OVe tO 

play the demo version of any 
game before I buy it. I n fact, as a gamer 
I purchase games based on how good 
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the demo is. As a developer, however, a 
demo version of a game is a tricky 
thing to pull off. In our case, most of 
the game's critical systems were not 
functioning on all cylinders and many 
game assets didn't exist yet. We had to 
dedicate most of our time and 
resources to this Cimmerian task, 
although all our schedule called for 
was a small tiger-team consisting of a 
designer, programmer, and artist who 
worked on it a small percentage of 
their day for about two weeks. 

When the smoke cleared and the 
demo was fin ally posted, the team gave 
a sigh of relief and basked in the 
warmth of a job well done. Unfortun- 
ately, this feeling quickly evaporated 
when we realized that we had taken 
almost a three-month departure from 
our original development schedule and 
totally exhausted ourselves in the 
process. I still believe a demo 
is i mportant to the success of 
a game, but such a task 
should be closely correlated 
to the production of 
the main SKU. 
Attempting to factor 
the demo development 
time and resources into a 
schedule significantly 
different from the game 
itself can profoundly 
affect both the prod- 
uct's quality and 
timeliness. 

2 Undocumented 
# TURNOVER. Th i s i s a very com- 
mon yet unpredictable aspect of game 
development. New and better jobs or 
personal issues always seem to snatch 
away even the most loyal and dedicat- 
ed teammates. Asa result, someone 
i n h eri ts th e worki oad of th e f al I en 
comrade, putting the team and the 
schedule in a precarious situation. 

When turnover occurred on the 
Heavy Gear II team, we and our 
schedule encountered a nasty surprise. 
Many of thesystems we inherited 
were only partially implemented and 
virtually undocumented. To make 
things worse, much of the code was 
written to implement advanced ani- 
mation and mathematical methods 
used all over the game engine, and we 
didn't have a technical design docu- 
ment that we could refer to in order to 
determine the intended solution for 
these systems. Working around the 



bugs and limitations in these systems 
cost the team even more time and 
generated bushels of frustration. This 
aspect of the turnover phenomenon is 
the least respected by developers and 
has the most profound and variable 
effect on scheduling. A periodic and 
thorough code review process is an 
effective way to defeat this problem. 

3 Schedule too aggressive. H eavy 
# Gear II was built completely 
from the battleground up, so every 
aspect of the game required significant 
development time. Unfortunately, the 
development schedule was too opti- 
mistic about how long it would take to 
create the title. 

Here's an idea of the scope of the 
game, as specified by our design docu- 
ment. Heavy Gear II required a brand 
new game engine and an accompany- 
ing suite of design, development, and 
debugging 

tools. ' " J y 




\ 



The game had 
more than 40 single- 
player missions, as well as 
numerous historical and instant-action 
missions. Additionally, multiplayer 
functionality (including cooperative 
play with multiplayer Al) was required 
for death match, king of the hill, steal 
the beacon, and historical settings. We 
were also required to construct three 
different modes for each and all of 
these missions: terrestrial, space, and 
"Gomorrah" (combat in an enclosed, 
multi-level, near-future megacity) gam- 
ing modes. 

Theschedulecalled for a polished 
demo version of the game to be posted 
on all of the top gaming web sites. I 
joined Activision on November 10, 
1997, after Heavy Gear II 's first proto- 
type, and the final product was initially 
slated for release for Christmas of the 
following year. This period included a 
protracted QA run-through, effectively 
yielding a nine-month development 
cycle. Unfortunately, it was far too 



aggressive. Although we implemented 
all of the required features as defined in 
the original design specification (and 
many not included), we missed our 
final ship date of October 1998 by nine 
months. 

4 Eleventh-hour SOLUTIONS. During 
# the production of Heavy Gear 
II, many of our game designers and 
external testers began to notice a dis- 
ti n ct absen ce of th ri 1 1 i n g game p I ay, 
which were attri buted to several fac- 
tors: theAl was too vicious, the Al -con- 
trol led squadmates were disobedient 
and difficult to deal with, and there 
was no noticeable ramp-up in difficulty 
and emotion — some missions were 
frightfully easy and others absolutely 
impossibleto complete. (Theaverage 
life expectancy of the player in some of 
our combat scenarios was about four 
seconds.) 

Our design team felt that they didn't 
have proper tools and enough control 
over theAl and the environ- 
ment to adequate- 
ly tune 
their mis- 
sions and make 
the game fun. 
Most of this 
was due to the 
fact that we 
arrogant 
program- 
mers designed and implemented most 
of the game logic without enough con- 
sultation and input from our able 
game design staff. To address these 
issues, our team had to depart totally 
from the design document and do a 
whole bunch of wild and creative 
thinking. Only after some ad hoc 
brainstorming sessions and grueling 
mission-by-mission playability tests 
did the pieces come together. Much of 
the kudos we received from the gam- 
ing community is directly related to 
these solutions. 

However, a situation I ike this could 
have had far worse results. The next 
time around we will put much more 
thought and detail into our game 
design documents and provide a much 
more efficient education for our game 
design staff concerning game play 
manipulation and control via scripts. 
We will also give them a more promi- 
nent role in the initial design of these 
systems to enhance their understand- 
ing of the underlying technology. 
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5 Marketing issues. 
# After experienc- 
ing the high quality of 
our second prototype, 
people at Acti vision 
began to get very excited 
about the future of 
H EAVY Gear II . We were 
given a highly favorable 
reception at E3 in 1998, 
where we fin ally revealed 
the game. We subse- 
quently released a 
playable demo that met 
with si m i I ar acceptan ce. 
Our marketing staff, 
which had been pushing 
thistitlefrom thestart, finally had the 
leverage it needed to differentiate 
Heavy Gear II from its competitors. 
Magazine articles began to run, OEM 
deals were made, and shelf displays 
were created as everyone anticipated 
the forthcoming release. 

Only the development team knew 
how alarmingly behind schedulethe 
game actually was, however. This was 
due i n part because of some unfortu- 
nate turn over in our staff, but the main 




factor was the amount of time and 
effort we had allocated to creating the 
demo. We had hit roadblocks in the 
past and always rebounded in sterling 
fashion, so nobody on our team 
allowed themselves to believe that the 
demo would cause us to miss our target 
ship date. 

Then we slipped. Suddenly we were 
plunged into a nearly interminable 
crunch mode. Our slip meant that the 
game wouldn't ship in timefor the 



Christmas season, so we 
decided to shoot for a 
more realistic March 
release. Our marketing 
group did their best to 
respond to the blow and 
attempted to keep interest 
in Heavy Gear II alive. 
March came and went, 
and the release date 
became a dancing phan- 
tom beyond our reach. We 
developers knew we were 
close to completing the 
game, but nobody could 
give our marketing team a 
definite date so that they 
could keep the buzz up. Marketing did 
what it could to keep whetting the 
publ ic's appetite as the weeks rol led by. 

M issing the targeted ship date is a 
serious risk to teams that rely on new 
and unproven technologies — and it's 
especially perilousfor teams working 
under compressed development sched- 
ules. Even the most innocuous develop- 
ment tasks, if underestimated or mis- 
handled, can send your schedule flitting 
away beyond your control . 
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Ue Almost Got It Right... 

We received great reviews from 
top gaming publications and 
web sites. Our marketing group 
piqued the interest of the gaming 
community and our development 
team produced a superior title. And 



since our development team had the 
luxury of starting this project from 
scratch, we had the opportunity to 
learn a wide range of new methods 
and techniques that would otherwise 
have remained beyond our reach. 

Alas, our aggressive schedule and 
risk taking proved to be our Achilles' 



heel. Shipping a quality title is impor- 
tant, but so is strict adherence to 
budget and schedule. The Heavy Gear 
II team learned a great deal from this 
experience; we'll keep that with us for 
a long time. At least we left a solid 
and reusable game engine in our 
wake. ■ 
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uman naturebeing what it is, I was hugely 
flattered to beasl<ed to participate in the 
September 1999 PC Gamer article about 
the 25 most talented people in gaming — 



the one they titled "Game Gods," lead- 
ing to no end of entirely justified rib- 
bing around Ion Storm's Austin 
offices.... 

Ribbing aside, such an honor repre- 
sents an almost un match able expres- 
sion of respect from journalists, peers 
and gamers — the sort of thing one 
works a lifetime to achieve. It may sur- 
prise you, then, that I almost turned 
the opportunity down. 

Why? 

Well, thecrux of thebiscuit isthat it 
seems unseemly and, more important, 
in appropriate to single people out for 
"star treatment" in a business as 
intensely col laborati ve as game devel- 
opment. Before getting into gaming, I 
always figured I'd end up making 
movies and spent a lot of time studying 
that business— you know, "film, the 
collaborative art...." Well, I'm hereto 
tell you that there is no more collabora- 
tive medium than gaming. The movies 
got nothin' on us, friends. There are so 
few renaissance game creators it's hard- 
ly worth the effort of identifying and 
listing them. 

In fact, honoring individuals repre- 
sents an almost criminal denial of the 
critical contributions of the dozens of 
team members who are, if anything, 
more responsi ble for the success of the 
games you know and love than the 
individualstypically credited with the 
creation of those games. And the eleva- 
tion of individuals to star status, while 
understandable in this increasingly 
marketing-driven age, symbolizes 



much of what I dislike about the game 
business as we approach themillenni- 
um. But let me be more specific. 

I've been credited with the creation of 
Underworld and System Shock, hon- 
ored as "The Man" behind Ultima VII, 
Part 2: Serpent Isle, cited as the creative 
force behind the "underappreciated" 

WiNGSOF 



Glory. 




illustration by Jackie Urbanovic 

As anyone who knows me will tell you, 
I'm intensely proud of those titles and 
my contributions to them. All of them 
appear on my resume, points of pride 
and high -water marks in a career that 
also includes some real clinkers. 
(Thankfully, no one much talks about 
the bad ones anymore but buy me a 
drink sometime, and I'll tell you hor- 
ror stories....) Frankly, I find being 



Warren Spector runs Ion Storm's Austin, Texas, office. He is currently working on a 
new role-playing game, Deus Ex. In the past, he has produced games for Origin and 
Looking Glass Technologies. You can reach him at wspector@ionstorm.com. 



credited with those titles — the good 
and the bad — vaguely embarrassing. 
It would certainly be the height of 
arrogance for me to takesoleor even 
majority credit for them. 

Underworld and System Shock 
would have amounted to nothing — 
wouldn't have happened at all — with- 
out the initial impetus provided by 
Blue Sky Productions' founder Paul 
Neurath. UW and Shock would never 
have been as cool or memorable as 
they were without the inspirational 
leadership of project director Doug 
Church (the Most Talented Individual 
I've worked with in this team-oriented 
business, if you must know). And let's 
not forget the contributions of pro- 
grammers like Marc LeBlanc, Rob 
Fermier, Art M in, Jon Maiara, Dan 
Schmidt, and James Fleming, or 
designers I ike Tim Stellmach and 
Dorian Hart, or audio guys like Greg 
Lo Piccolo and Eric Brosius, or testers 

like Harvey Smith. Underworld and 

System Shock are their creations, 
not mine. More accurately, they are 

our creations, all of us applying our 
unique, individual talents to the 
accomplishment of mutually agreed- 
upon goals. 

Similarly, Serpent Isle is the product 
of more than 30 hearts, minds, and 
souls. I came up with a tone and "feel" I 
wanted to achieve and a story concept. I 
set some parameters on the world and 
characters. But the minute-to-minute 
details of the storyline were fleshed out 
by some amazingly talented designers 
— Steve Powers, Dave Beyer, Bill 
Armintrout, and others. And I watched, 
usually with jaw on ground, as lead 
artist Denis Loubet and the rest of the 
art team brought to life the world and 
characters of Serpent Isle. And without 
testers I i ke M arshal I Andrews, the game 
wouldn't have been half what it ended 
up being. I built not one inch of the 
map, wrote not one line of dialogue, 
implemented not one game function. 
So whose game is it? 

Continued on page 71. 
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Continued from page 72. 

Wings OF Glory was largely the same 
thing. I came up with an idea, a feeling 
I wanted to evoke during play. I worked 
with a design team ultimately led by 
Dave Beyer to craft a story and basically 
nodded my head a lot in stunned agree- 
ment as lead artist Whitney Ayres craft- 
ed the perfect look for the game. I 
watched, often dumbstruck, as pro- 
grammers Bill Baldwin, Tony Bratton, 
and John Tal ley brought to near perfect 
lifethevision I had in my head when 
we started. Who deserves credit for 
WiNGSOF Glory? 

When "Warren Spector's Deus Ex" 
comes out, will people acknowledge 
th e i n cred i bl e con tri buti on s of I ead 
programmer Chris Norden, lead 
designer Harvey Smith, lead artist Jay 
Lee, and the rest of the team? Odds 
are, they won't and I'll end up writing 
more articles and posting more Usenet 
messages and talking to more journal- 
ists to convince gamers that individu- 
als don't make great games — great 
teams do. 

Now, maybe there are a couple of 
guys in the list of "Game Gods" who 
are one-man shows. I certainly find 
myself in awe of John Carmack, Peter 



Molyneux, Sid Meier, and some others 
in the PC Gamer group. (And, man, did 
I geek out and have a great time hang- 
ing with them!) Maybe I'm theanom- 
aly. I doubt it, though. I'm willing to 
bet we're all team-oriented guys. 

I suspect the impetus to singleout 
one person for credit (or blame) is 
some kind of human need for short- 
hand, a way to separate wheat (good 
games) from chaff (bad games) with 
some simple formula based on past 
successes. Or maybe the spotlight 
turned on individual game developers, 
making some of us "brand names," is 
just an easy way for marketing guys to 
earn their salaries. I don't know. 

What I do know isthat I'd be 
nowhere without the teams that have 
backed me up and often dragged me, 
kicking and screaming, toward success. 
And before anyone starts assuming I'm 
beingfalsely modest, let me assure you I 
have quite enough ego for several ordi- 
nary mortals. I know I'm a good design- 
er, a good process manager, a good peo- 
ple manager, a good business guy, and 
I'm even O.K. at the PR end of things. 
There are certai n ly others who are better 
than I am at any one of those things. 



but put them al I together and you've 
got a package I 've come to see as pretty 
rare over the years, one that allows me 
to play to the strengths and help over- 
come the weaknesses of almost any 
team. I'm not being modest. But "Game 
God"?Hmm? 

Anyway, if you're a producer, project 
director, or Game God, reflect for a 
moment as you talk to the press, pub- 
lishers, and PR people on all the unsung 
heroes whose names are never men- 
tioned. Think of their contributions to 
"your" success and to the "individual" 
successes of the other lucky folks lauded 
on gaming web sites and in the pages of 
game magazines. Give credit where 
credit is due. I know it's hard. I know 
the press doesn't want to hear this. But 
do it anyway because it'sthe right thing 
to do. 

And if you're one of the unsung, 
well, all I can say is hang in there. We 
may live in a PR world nowadays, but 
your contributions are appreciated by 
people who "get it." And maybe — 
just maybe — if we all start talking 
about this, someone will start listen- 
ing and you'll get your well-earned 
day in the sun. m 
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